Was ist Säure in MySQL?

Dieser Artikel stellt Ihnen Säure in MySQL vor. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.

1. Grundelemente von Transaktionen (ACID)

1. Atomarität: Nach Beginn einer Transaktion sind alle Vorgänge entweder abgeschlossen oder nicht abgeschlossen, und es ist unmöglich, in der Mitte zu stagnieren. Wenn während der Transaktionsausführung ein Fehler auftritt, wird die Transaktion auf den Zustand vor Beginn der Transaktion zurückgesetzt und alle Vorgänge werden so ausgeführt, als ob sie nicht stattgefunden hätten. Das heißt, die Materie ist ein unteilbares Ganzes, genau wie die in der Chemie erlernten Atome, die die Grundeinheiten der Materie darstellen.

　 2. Konsistenz: Vor und nach Beginn und Ende der Transaktion werden die Integritätsbeschränkungen der Datenbank nicht zerstört. Wenn A beispielsweise Geld an B überweist, ist es unmöglich, dass A das Geld abzieht, B es aber nicht erhält. Tatsächlich ist Konsistenz auch eine Manifestation der Atomizität

　 3. Isolation: Gleichzeitig darf nur eine Transaktion dieselben Daten anfordern, und es gibt keine Interferenzen zwischen verschiedenen Transaktionen. Beispielsweise kann A Geld von einer Bankkarte abheben, bevor der Abhebungsvorgang von A abgeschlossen ist. Serialisierung

　 4. Haltbarkeit: Nach Abschluss der Transaktion werden alle Aktualisierungen der Datenbank durch die Transaktion in der Datenbank gespeichert und können nicht zurückgesetzt werden. 2. Probleme mit der Parallelität von Transaktionen in der Tabelle. Die tatsächlichen Daten sind inkonsistent

　2. Nicht wiederholbares Lesen: Transaktion A liest dieselben Daten mehrmals, und Transaktion B aktualisiert und übermittelt die Daten während der mehrfachen Lesevorgänge von Transaktion A, was dazu führt, dass Transaktion A dieselben liest Daten mehrmals, die Ergebnisse sind inkonsistent. Das Leseergebnis stimmt nicht mit dem letzten Ergebnis überein　3. Phantomlesung: Systemadministrator A hat die Noten aller Schüler in der Datenbank von bestimmten Ergebnissen in ABCDE-Noten geändert, aber Systemadministrator B hat zu diesem Zeitpunkt einen Datensatz mit bestimmten Ergebnissen eingefügt Systemadministrator A schloss die Änderung ab und stellte fest, dass noch ein Datensatz vorhanden war, der nicht geändert wurde. Dies war wie eine Halluzination. Dies wird als Phantomlesung bezeichnet. Es wurde modifiziert, dann aber geändert, was zu einem anderen Ergebnis als erwartet führte

Zusammenfassung: Nicht wiederholbares Lesen und Phantomlesen werden leicht verwechselt. Nicht wiederholbares Lesen konzentriert sich auf Änderungen, und Phantomlesen konzentriert sich auf das Hinzufügen oder Löschen. Um das Problem nicht wiederholbarer Lesevorgänge zu lösen, müssen Sie nur die Zeilen sperren, die die Bedingungen erfüllen. Um das Problem der Phantom-Lesevorgänge zu lösen, müssen Sie die Tabelle 3 sperren. MySQL-Transaktionsisolationsstufe Phantom-Lesen -uncommitted

yes

yes

yes

read-committed

MySQLs Standard-Transaktionsisolationsstufe ist wiederholbares Lesen

IV. Verwenden Sie Beispiele, um jede Isolationsstufe zu veranschaulichen

　1. Nicht festgeschrieben lesen:

　　　 (1) Öffnen Sie einen Client A und legen Sie den aktuellen Transaktionsmodus fest Nicht festgeschrieben lesen (nicht festgeschrieben lesen), und der Anfangswert des Abfragetabellenkontos ist:

　 (2) Bevor die Transaktion von Client A übermittelt wird, öffnen Sie einen anderen Client B und aktualisieren Sie das Tabellenkonto:

(3) Zu diesem Zeitpunkt kann Client A, obwohl die Transaktion von Client B noch nicht übermittelt wurde, die aktualisierten Daten von B abfragen:

　　 (4) Sobald die Transaktion von Client B aus irgendeinem Grund unterbrochen wird, werden alle Vorgänge rückgängig gemacht , und die von Client A abgefragten Daten sind tatsächlich schmutzige Daten:

　　　　 (5) Führen Sie die Update-Anweisung auf Client A aus. Aktualisieren Sie das Konto. Set Balance = Balance - 50, wobei ID = 1, Lileis Balance wurde nicht 350, sondern tatsächlich 400. Ist es nicht seltsam? Wenn Sie das denken, werden wir 400-50 = 350 verwenden Um dieses Problem zu lösen, können Sie die Isolationsstufe „Read Committed“ verwenden des Tabellenkontos:

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 Entweder im Commit-Read >> “ Die Transaktion von Client B konnte die aktualisierten Daten von B noch nicht abfragen, was das Dirty-Read-Problem löst:

　　　　　　　　　　　　　　　　　　　　　　　　　　　　Knochen oben im Klienten A  (1) Abfrage:

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ulous in 50, wobei id = 1, der Saldo nicht 400-50=350 wird, wird Lileis Saldowert unter Verwendung der 350 in Schritt (2) berechnet, also ist er 300, die Konsistenz des Daten werden nicht zerstört, das ist ein bisschen magisch, vielleicht ist es eine Funktion von MySQL. Bei der Ausführung von DML können die Daten entsprechend den tatsächlichen Daten in der Tabelle wiederholt gelesen werden

mysql> select * from account;
+------+--------+---------+
| id   | name   | balance |
+------+--------+---------+
|    1 | lilei  |     400 |
|    2 | hanmei |   16000 |
|    3 | lucy   |    2400 |
+------+--------+---------+
3 rows in set (0.00 sec)

mysql> update account set balance = balance - 50 where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from account;
+------+--------+---------+
| id   | name   | balance |
+------+--------+---------+
|    1 | lilei  |     300 |
|    2 | hanmei |   16000 |
|    3 | lucy   |    2400 |
+------+--------+---------+
3 rows in set (0.00 sec)

，站在客户的角度，客户是看不到客户端B的，它会觉得是天下掉馅饼了，多了600块，这就是幻读，站在开发者的角度，数据的 一致性并没有破坏。但是在应用程序中，我们得代码可能会把18700提交给用户了，如果你一定要避免这情况小概率状况的发生，那么就要采取下面要介绍的事务隔离级别“串行化”

mysql> select sum(balance) from account;
+--------------+ 
| sum(balance) | 
+--------------+ 
| 18700 |
+--------------+
1 row in set (0.00 sec)
mysql> commit;
 Query OK, 0 rows affected (0.00 sec)
mysql> select sum(balance) from account;
 +--------------+ 
 | sum(balance) | 
 +--------------+
 | 19300 |
 +--------------+ 
 1 row in set (0.00 sec)

　　4.串行化

　　　　（1）打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值：

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from account;
+------+--------+---------+
| id   | name   | balance |
+------+--------+---------+
|    1 | lilei  |   10000 |
|    2 | hanmei |   10000 |
|    3 | lucy   |   10000 |
|    4 | lily   |   10000 |
+------+--------+---------+
4 rows in set (0.00 sec)

　　　　（2）打开一个客户端B，并设置当前事务模式为serializable，插入一条记录报错，表被锁了插入失败，mysql中事务隔离级别为serializable时会锁表，因此不会出现幻读的情况，这种隔离级别并发性极低，开发中很少会用到。

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into account values(5,'tom',0);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

补充：

　　1、SQL规范所规定的标准，不同的数据库具体的实现可能会有些差异

　　2、mysql中默认事务隔离级别是可重复读时并不会锁住读取到的行

　　3、事务隔离级别为读提交时，写数据只会锁住相应的行

　　4、事务隔离级别为可重复读时，如果有索引（包括主键索引）的时候，以索引列为条件更新数据，会存在间隙锁间隙锁、行锁、下一键锁的问题，从而锁住一些行；如果没有索引，更新数据时会锁住整张表。

　　5、事务隔离级别为串行化时，读写数据都会锁住整张表

　　 6、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大，鱼和熊掌不可兼得啊。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

相关推荐：《mysql教程》

Das obige ist der detaillierte Inhalt vonWas ist Säure in MySQL?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!