Ein Artikel, der die Prinzipien von Transaktionen und MVCC in MySQL ausführlich erklärt

Dieser Artikel wird Ihnen helfen, die Transaktionen in MySQL zu verstehen und das Prinzip von MVCC vorzustellen. Ich hoffe, er kann Ihnen helfen!

01 Was ist eine Transaktion?

Eine Datenbanktransaktion bezieht sich auf eine Reihe von Datenvorgängen, die entweder alle erfolgreich sind oder fehlschlagen. Tatsächlich ist es nicht so, dass ein Teil davon ausgeführt wird erledigt, aber solange ein Schritt fehlschlägt, wird das Zurücksetzen aller Vorgänge ein bisschen so sein, als würde man nichts tun, ohne etwas anderes zu tun.

In MySQL wird die Transaktionsunterstützung auf der Engine-Ebene implementiert. MySQL ist ein System, das mehrere Engines unterstützt, aber nicht alle Engines unterstützen Transaktionen. Zum Beispiel unterstützt die native MyISAM-Engine von MySQL keine Transaktionen, was einer der wichtigen Gründe ist, warum MyISAM durch InnoDB ersetzt wurde.

1.1 Vier Hauptmerkmale

• Atomizität: Nach Beginn der 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.
• Konsistenz: Die Integritätsbeschränkungen der Datenbank werden vor und nach Beginn der Transaktion nicht verletzt. Wenn A beispielsweise Geld an B überweist, ist es A unmöglich, das Geld abzuziehen, B es jedoch nicht erhält.
• Isolation: Nur eine Transaktion darf gleichzeitig 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.
• Dauerhaftigkeit: Nach Abschluss der Transaktion werden alle Aktualisierungen der Datenbank durch die Transaktion in der Datenbank gespeichert und können nicht zurückgesetzt werden.

1.2 Isolationsstufe

Unter den vier Merkmalen von SQL-Transaktionen sind Atomizität, Konsistenz und Haltbarkeit alle relativ leicht zu verstehen. Aber die Isolationsstufe von Transaktionen ist tatsächlich schwierig. Heute werden wir hauptsächlich über die Isolation von MySQL-Transaktionen sprechen.

SQL-Standard-Transaktionsisolationsstufen von niedrig bis hoch sind: read uncommitted (read uncommitted), read commit (read commited), wiederholbares Lesen (repeatable read) und serializable (serialisierbar). Je höher das Niveau, desto geringer ist der Wirkungsgrad.

• Nicht festgeschrieben lesen: Wenn eine Transaktion nicht festgeschrieben wurde, können die von ihr vorgenommenen Änderungen von anderen Transaktionen gesehen werden.
• Commit lesen: Nachdem eine Transaktion festgeschrieben wurde, werden die vorgenommenen Änderungen von anderen Transaktionen gesehen.
• Wiederholbares Lesen: Die während der Ausführung einer Transaktion angezeigten Daten stimmen immer mit den Daten überein, die beim Start der Transaktion angezeigt werden. Natürlich sind unter der wiederholbaren Leseisolationsstufe nicht festgeschriebene Änderungen auch für andere Transaktionen unsichtbar.
• Serialisierung: Wie der Name schon sagt, fügt „Schreiben“ für dieselbe Datensatzzeile eine „Schreibsperre“ und „Lesen“ eine „Lesesperre“ hinzu. Wenn ein Lese-/Schreibsperrenkonflikt auftritt, muss die Transaktion, auf die später zugegriffen wird, auf den Abschluss der vorherigen Transaktion warten, bevor sie weiter ausgeführt werden kann. Alle Daten unter dieser Isolationsstufe sind also am stabilsten, aber die Leistung ist auch am schlechtesten.

1.3 Gelöste Parallelitätsprobleme

Die SQL-Transaktionsisolationsstufe ist darauf ausgelegt, Parallelitätsprobleme weitestgehend zu lösen:

• Dirty Read: Transaktion A liest die von Transaktion B aktualisierten Daten, und dann gibt B den Roll-Vorgang zurück Dann handelt es sich bei den von A gelesenen Daten um schmutzige Daten Wenn Daten mehrmals eingegeben werden, sind die Ergebnisse inkonsistent.
• Phantomlesung: Systemadministrator A hat die Noten aller Schüler in der Datenbank von bestimmten Noten in ABCDE-Noten geändert, aber Systemadministrator B hat zu diesem Zeitpunkt einen Datensatz mit bestimmten Noten eingefügt. Als Systemadministrator A die Änderung abschloss, stellte er fest, dass dies der Fall ist ein weiterer Datensatz, der nicht verändert wurde, als ob eine Halluzination aufgetreten wäre. Dies wird als Phantomlesung bezeichnet.
• Verschiedene SQL-Transaktionsisolationsstufen können unterschiedliche Parallelitätsprobleme lösen, wie in der folgenden Tabelle gezeigt:

Nur die Serialisierungsisolationsstufe löst alle drei Probleme, und die anderen drei Isolationsstufen weisen Mängel auf

.

Transaction Isolation LevelRead UncommittedEingereicht lesen

PS: Es ist leicht, nicht wiederholbares Lesen und Phantomlesen zu verwechseln. Beim nicht wiederholbaren Lesen geht es um Änderungen, während beim Phantomlesen das Hinzufügen oder Löschen im Vordergrund steht. Um das Problem des nicht wiederholbaren Lesens zu lösen, müssen Sie nur die Zeilen sperren, die die Bedingungen erfüllen. Um das Problem des Phantomlesens zu lösen, müssen Sie die Tabelle sperren

1.4 Geben Sie mir ein Beispiel

Dies Vielleicht ist es etwas schwer zu verstehen. Lassen Sie mich ein Beispiel geben. Es handelt sich immer noch um die vorherige Tabellenstruktur und die Tabellendaten das Alter des Schülers mit id = 2 . Der Prozess ist wie folgt.

Was sind die Werte von X1, X2 und X3 unter den vier Isolationsstufen?

Nicht festgeschrieben lesen: Der Wert von X1 ist 23, denn obwohl Transaktion B nicht festgeschrieben wurde, wurden ihre Änderungen von A gesehen. (

Wenn B später den Wert von X1 zurücksetzt, ist es schmutzig). Die Werte von X2 und X3 betragen ebenfalls 23, was verständlich ist. Eingereicht lesen: Der Wert von X1 ist 22, denn obwohl sich B geändert hat, kann A ihn nicht sehen. (

Wenn B später zurückgesetzt wird, bleibt der Wert von X1 unverändert, wodurch das Problem des schmutzigen Lesens gelöst wird.) Die Werte von X2 und

• Wiederholbare Lesung: X1 und (Egal wie B in diesem Zeitraum geändert wird, solange A nicht eingereicht hat, ist es unsichtbar, was das Problem des nicht wiederholbaren Lesens löst) und der Wert von X3 ist 23, da A eingereicht hat. und der geänderte Wert von B ist zu sehen.
• Serialisierung: B wird während der Durchführung von Änderungen gesperrt, bis A festschreibt. B kann die Ausführung fortsetzen. (Während A liest, kann B nicht schreiben. Es muss sichergestellt werden, dass die Daten zu diesem Zeitpunkt auf dem neuesten Stand sind. Das Phantomlesen ist gelöst) X1 und X2 sind also beide 22, und das letzte X3 wird ausgeführt, nachdem B übermittelt wurde. und sein Wert ist 23.
• Warum kommt es dann zu diesem Ergebnis? Wie wird die Transaktionsisolationsstufe implementiert?
Wie wird die Transaktionsisolationsstufe implementiert? Ich habe die Antwort in der Klasse von Lehrer Ding Qi bei Geek Time gefunden:
• Tatsächlich wird eine Ansicht in der Datenbank erstellt, und das logische Ergebnis der Ansicht hat beim Zugriff Vorrang. Unter der Isolationsstufe „Wiederholbarer Lesevorgang“ wird diese Ansicht beim Start der Transaktion erstellt und während der gesamten Transaktion verwendet. Unter der Isolationsstufe „read-committed“ wird diese Ansicht am Anfang jeder SQL-Anweisung erstellt. Hierbei ist zu beachten, dass unter der Isolationsstufe „Lesen nicht festgeschrieben“ der neueste Wert im Datensatz direkt zurückgegeben wird, ohne das Konzept einer Ansicht, während unter der Isolationsstufe „Serialisierung“ die Sperre direkt verwendet wird, um Parallelen zu vermeiden Zugang
.

1.5 Transaktionsisolationsstufe festlegen

Die von verschiedenen Datenbanken festgelegten Standard-Transaktionsisolationsstufen sind ebenfalls sehr unterschiedlich. Die Standardisolationsstufe der Oracle-Datenbank ist

read commited

, während MySQL repeatable read ist. Deshalb: Wenn Ihr System die Datenbank von Oracle nach MySQL migrieren muss, stellen Sie bitte vor der Migration die Ebene so ein, dass sie damit übereinstimmt (Lesen und Festschreiben), um unvorhersehbare Probleme zu vermeiden. 1.5.1 Transaktionsisolationsstufe anzeigen level]

Der Geltungsbereich ist optional: SESSION (Sitzung), GLOBAL (global); die Isolationsebene ist die oben erwähnte und unterscheidet nicht zwischen Groß- und Kleinschreibung. Zum Beispiel: Stellen Sie die globale Isolationsstufe auf „Committed“ ein

CREATE TABLE `student`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `age` int(11) NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 66 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

1.6 Transaktionsstart

MySQL-Transaktionen können auf folgende Weise gestartet werden:

• 显式启动事务语句， begin 或 start transaction。配套的提交语句是 commit，或者回滚语句是 rollback。

# 更新学生名字
START TRANSACTION;
update student set name = '张三' where id = 2;
commit;

• set autocommit = 0，这个命令会将线程的自动提交关掉。意味着如果你只执行一个 select 语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行 commit 或 rollback 语句，或者断开连接。
• set autocommit = 1，表示 MySQL 自动开启和提交事务。 比如执行一个 update 语句，语句只完成后就自动提交了。不需要显示的使用 begin、commit 来开启和提交事务。所以当我们执行多个语句的时候，就需要手动的用 begin、commit 来开启和提交事务。
• start transaction with consistent snapshot；上面提到的 begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用 start transaction with consistent snapshot 命令。 第一种启动方式，一致性视图是在执行第一个快照读语句时创建的； 第二种启动方式，一致性视图是在执行 start transaction with consistent snapshot 时创建的。

02 事务隔离的实现

理解了隔离级别，那事务的隔离是怎么实现的呢？要想理解事务隔离，先得了解 MVCC 多版本的并发控制这个概念。而 MVCC 又依赖于 undo log 和 read view 实现。

2.1 什么是 MVCC？

百度上的解释是这样的：

MVCC，全称 Multi-Version Concurrency Control，即多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

MVCC 使得数据库读不会对数据加锁，普通的 SELECT 请求不会加锁，提高了数据库的并发处理能力；数据库写才会加锁。 借助 MVCC，数据库可以实现 READ COMMITTED，REPEATABLE READ 等隔离级别，用户可以查看当前数据的前一个或者前几个历史版本，保证了 ACID 中的 I 特性（隔离性)。

MVCC 只在 REPEATABLE READ 和 READ COMMITIED 两个隔离级别下工作。其他两个隔离级别都和 MVCC 不兼容 ，因为 READ UNCOMMITIED 总是读取最新的数据行，而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。

2.1.1 InnDB 中的 MVCC

InnDB 中每个事务都有一个唯一的事务 ID，记为 transaction_id。它在事务开始时向 InnDB 申请，按照时间先后严格递增。

而每行数据其实都有多个版本，这就依赖 undo log 来实现了。每次事务更新数据就会生成一个新的数据版本，并把  transaction_id 记为 row trx_id。同时旧的数据版本会保留在 undo log 中，而且新的版本会记录旧版本的回滚指针，通过它直接拿到上一个版本。

所以，InnDB 中的 MVCC 其实是通过在每行记录后面保存两个隐藏的列来实现的。一列是事务 ID：trx_id；另一列是回滚指针：roll_pt。

2.2 undo log

回滚日志保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。

根据操作的不同，undo log 分为两种： insert undo log 和 update undo log。

2.2.1 insert undo log

insert 操作产生的 undo log，因为 insert 操作记录没有历史版本只对当前事务本身可见，对于其他事务此记录不可见，所以 insert undo log 可以在事务提交后直接删除而不需要进行 purge 操作。

purge 的主要任务是将数据库中已经 mark del 的数据删除，另外也会批量回收 undo pages

所以，插入数据时。它的初始状态是这样的：

2.2.2 update undo log

UPDATE 和 DELETE 操作产生的 Undo log 都属于同一类型：update_undo。（update 可以视为 insert 新数据到原位置，delete 旧数据，undo log 暂时保留旧数据）。

事务提交时放到 history list 上，没有事务要用到这些回滚日志，即系统中没有比这个回滚日志更早的版本时，purge 线程将进行最后的删除操作。

Eine Transaktion ändert die aktuellen Daten:

Eine andere Transaktion ändert die Daten:

Es gibt mehrere Versionen desselben Datensatzes in der Datenbank, bei der es sich um das erwähnte Multiversions-Parallelitätskontroll-MVCC handelt über .

Darüber hinaus können Sie das Rückgängig-Protokoll verwenden, um zum vorherigen Versionsstand zurückzukehren. Um beispielsweise zu V1 zurückzukehren, müssen Sie nur zwei Rollbacks nacheinander durchführen.

2.3 Leseansicht

Die Leseansicht ist eine konsistente Leseansicht, die von InnDB bei der Implementierung von MVCC verwendet wird, um die Implementierung der Isolationsstufen RC (Read Commit) und RR (Repeatable Read) zu unterstützen.

Die Leseansicht existiert nicht wirklich, sie ist nur ein Konzept und das Rückgängig-Protokoll ist ihre Verkörperung. Es wird hauptsächlich durch Version und Undolog berechnet. Seine Funktion besteht darin, zu bestimmen, welche Daten die Transaktion sehen kann.

Jede Transaktion oder Abrechnung verfügt über eine eigene Konsistenzansicht. Gewöhnliche Abfrageanweisungen sind konsistente Lesevorgänge, die die Sichtbarkeit der Datenversion basierend auf der Zeile trx_id und konsistenten Ansichten bestimmen.

2.3.1 Sichtbarkeitsregeln der Datenversion

Die Leseansicht enthält hauptsächlich andere aktive Lese- und Schreibtransaktionen im aktuellen System. Bei der Implementierung erstellt InnDB ein Array für jede Transaktion, um den Moment zu speichern, in dem diese Transaktion beginnt. Es handelt sich derzeit um eine aktive (noch nicht übermittelte) Transaktion.

Wie bereits erwähnt, steigt die Transaktions-ID mit der Zeit strikt an.

Der Maximalwert der übermittelten Transaktions-ID im System wird als Niedrigwasserstand des Arrays aufgezeichnet, und die erstellte Transaktions-ID + 1 wird als Hochwasserstand aufgezeichnet Ebene.

Dieses Ansichtsarray und der Hochwasserstand bilden die Konsistenzansicht (Leseansicht) der aktuellen Transaktion.

Zeichnen Sie ein Bild dieses Arrays. Es sieht folgendermaßen aus:

Die Regeln lauten wie folgt : 1 Wenn trx_id Der graue Bereich zeigt an, dass die trx_id der Version, auf die zugegriffen wird, kleiner ist als der ID-Wert des niedrigen Wasserstands im Array, dh die Transaktion, die diese Version generiert hat, wurde vor der Generierung festgeschrieben die Leseansicht, sodass diese Version sichtbar ist und von der aktuellen Transaktion abgerufen werden kann.

2 Wenn sich trx_id im orangefarbenen Bereich befindet, bedeutet dies, dass die trx_id der Version, auf die zugegriffen wird, größer ist als der ID-Wert des Hochwasserstands im Array, dh die Transaktion, die diese Version generiert hat, wurde nach der Leseansicht generiert wurde generiert, daher ist diese Version unsichtbar und kann von der aktuellen Transaktion nicht aufgerufen werden.

• 3 Wenn es im grünen Bereich liegt, gibt es zwei Situationen:
• a) trx_id ist im Array, was beweist, dass diese Version durch eine nicht festgeschriebene Transaktion generiert wurde und unsichtbar ist

• b) trx_id ist nicht im Array Das Array zeigt, dass diese Version durch die übermittelte Transaktion generiert wird.

  • Der dritte Punkt war etwas verwirrend, als ich mir das Tutorial ansah. Glücklicherweise antworteten einige begeisterte Internetnutzer:
  hineinfallen Der grüne Bereich bedeutet, dass sich die Transaktions-ID im Bereich von niedrigem Wasserstand und hohem Wasserstand befindet. Ob sie wirklich sichtbar ist, hängt davon ab, ob der grüne Bereich diesen Wert hat. Wenn der grüne Bereich diese Transaktions-ID nicht hat, ist sie sichtbar, wenn ja, ist sie nicht sichtbar. In diesem Bereich zu liegen bedeutet nicht, dass dieser Bereich diesen Wert hat, z. B. [1,2,3,5], 4 liegt im Bereich von 1-5 dieses Arrays, aber nicht in diesem Array.

Das ist vielleicht etwas schwer zu verstehen: Drei Transaktionen fragen die gleichen Daten ab und aktualisieren sie zum leichteren Verständnis:

Die Originaldaten sind immer noch wie im Bild unten , aktualisiere die Informationen von Zhang San mit der ID = 2:

Zum obigen Bild möchte ich eine Frage stellen. Wie hoch sind unter den Isolationsstufen RC (Read Committed) und RR (Repeatable Read) die Abfragealterswerte zu den Zeitpunkten T4 bzw. T5? Was ist der aktualisierte Wert von T4? Denken Sie einen Moment darüber nach, ich glaube, jeder hat seine eigene Antwort. Die Antwort finden Sie am Ende des Artikels. Ich hoffe, Sie können mit Ihren eigenen Fragen weiterlesen.

2.3.2 Ergebnisse unter RR (Repeatable Read)

RR-Ebene erkennt die Abfrage nur die Daten, die vor dem Start der Transaktion übermittelt wurden, und die Ansicht wird erstellt, sobald die Transaktion gestartet wird. Verwenden Sie also den Befehl „Transaktion mit konsistentem Snapshot starten“ und die Ansicht wird sofort erstellt.

现在假设：

• 事务 A 开始前，只有一个活跃的事务，ID = 2，
• 已提交的事务也就是插入数据的事务 ID = 1
• 事务 A、B、C 的事务 ID 分别是 3、4、5

在这种隔离级别下，他们创建视图的时刻如下：

根据上图得，事务 A 的视图数组是[2,3]；事务 B 的视图数组是 [2,3,4]；事务 C 的视图数组是[2,3,4,5]。分析一波：

• T4 时刻，B 读数据都是从当前版本读起，过程是这样的：

  • 读到当前版本的 trx_id = 4，刚好是自己，可见
  • 所以 age = 24

• T5 时刻，A 读数据都是从当前版本读起，过程是这样的：

  • 读到当前版本的 trx_id = 4，比自己视图数组的高水位大，不可见
  • 再往上读到 trx_id = 5，比自己视图数组高水位大，不可见
  • 再往上读到 trx_id = 1，比自己视图数组低水位小，可见
  • 所以 age = 22

这样执行下来，虽然期间这一行数据被修改过，但是事务 A 不论在什么时候查询，看到这行数据的结果都是一致的，所以我们称之为一致性读。

其实视图是否可见主要看创建视图和提交的时机，总结下规律：

• 版本未提交，不可见
• 版本已提交，但在视图创建后提交，不可见
• 版本已提交，但在视图创建前提交，可见

2.3.2.1 快照读和当前读

事务 B 的 update 语句，如果按照上图的一致性读，好像结果不大对？

如下图周明，B 的视图数组是先生成的，之后事务 C 才提交。那就应该看不见 C 修改的 age = 23 呀？最后 B 怎么得出 24 了？

没错，如果 B 在更新之前执行查询语句，那返回的结果肯定是 age = 22。问题是更新就不能在历史版本更新了呀，否则 C 的更新不就丢失了？

所以，更新有个规则：更新数据都是先读后写（读是更新语句执行，不是我们手动执行），读的就是当前版本的值，叫当前读；而我们普通的查询语句就叫快照读。

因此，在更新时，当前读读到的是 age = 23，更新之后就成 24 啦。

2.3.2.2 select 当前读

除了更新语句，查询语句如果加锁也是当前读。如果把事务 A 的查询语句 select age from t where id = 2 改一下，加上锁（lock in mode 或者 for update），也都可以得到当前版本 4 返回的 age = 24

下面就是加了锁的 select 语句：

select age from t where id = 2 lock in mode;
 select age from t where id = 2 for update;

2.3.2.3 事务 C 不马上提交

假设事务 C 不马上提交，但是 age = 23 版本已生成。事务 B 的更新将会怎么走呢？

事务 C 还没提交，写锁还没释放，但是事务 B 的更新必须要当前读且必须加锁。所以事务 B 就阻塞了，必须等到事务 C 提交，释放锁才能继续当前的读。

2.3.3 RC（读提交）下的结果

在读提交隔离级别下，查询只承认在语句启动前就已经提交完成的数据；每一个语句执行之前都会重新算出一个新的视图。

注意：在上图的表格中用于启动事务的是 start transaction with consistent snapshot 命令，它会创建一个持续整个事务的视图。所以，在  RC 级别下，这命令其实不起作用。等效于普通的 start transaction（在执行 sql 语句之前才算是启动了事务）。所以，事务 B 的更新其实是在事务 C 之后的，它还没真正启动事务，而 C 已提交。

现在假设：

• Bevor Transaktion A beginnt, gibt es nur eine aktive Transaktion, ID = 2,
• Die festgeschriebene Transaktion ist die Transaktions-ID der eingefügten Daten = 1
• Die Transaktions-IDs der Transaktionen A, B und C sind 3, 4, bzw. 5.

Unter dieser Isolationsstufe ist der Moment, in dem sie die Ansicht erstellen, wie folgt:

Gemäß dem Bild oben ist das Ansichtsarray von Transaktion A [2,3,4], aber seine Obergrenze ist 6 oder höher (erstellte Transaktions-ID + 1); das Ansichtsarray von Transaktion B ist [2,4]; Eine Analysewelle:

• Zur T4-Zeit liest B Daten aus der aktuellen Version. Der Vorgang ist wie folgt:

  • liest die trx_id = 4 der aktuellen Version, die zufällig selbst ist dass
  • also Alter = 24

• Zum Zeitpunkt T5 liest A Daten aus der aktuellen Version. Der Vorgang ist wie folgt:

  • liest die trx_id = 4 der aktuellen Version, die im Gültigkeitsbereich liegt eigene Konsistenzansicht, enthält aber 4, was unsichtbar ist
  • Lesen Sie weiter bis zu trx_id = 5, was im Rahmen Ihrer eigenen Konsistenzansicht liegt, aber nicht 5 enthält. Es ist ersichtlich, dass
  • also Alter = 23

03 Die Schultern der Riesen cnblogs .com/xd502djj/p/6668632.html

blog.csdn.net/article /details/109044141

• blog.csdn.net/u014078930/article/details/99659272
• 04 Zusammenfassung
• Dieser Artikel behandelt Alle Aspekte von Transaktionen im Detail, wie zum Beispiel: vier Hauptfunktionen, Isolationsstufen, gelöste Parallelitätsprobleme, Einrichtung, Überprüfen der Isolationsstufe, Starten einer Transaktion usw. Darüber hinaus haben wir auch ein tiefes Verständnis dafür gewonnen, wie die beiden Isolationsstufen RR und RC erreicht werden? Einschließlich einer detaillierten Erklärung, wie MVCC, Undo-Log und Leseansicht zusammenarbeiten, um MVCC zu implementieren. Abschließend sprachen wir über Snapshot-Lesung, aktuelle Lektüre usw. Man kann sagen, dass hier alle Wissenspunkte im Zusammenhang mit Angelegenheiten vorhanden sind. Wenn Sie nach dem Lesen dieses Artikels immer noch nicht verstehen, kommen Sie und schlagen Sie mich!
• 【Verwandte Empfehlung:
• MySQL-Video-Tutorial
】

Dirty Read	Non-Repeatable Read	Phantom Read
Possible	Possible	Möglich
unmöglich	möglich

Das obige ist der detaillierte Inhalt vonEin Artikel, der die Prinzipien von Transaktionen und MVCC in MySQL ausführlich erklärt. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!