Der Inhalt dieses Artikels ist eine detaillierte Einführung (Bilder und Texte) zum Implementierungsprinzip der ACID-Funktion. Es hat einen gewissen Referenzwert es hilft.

Transaktionen sind ein wichtiger Aspekt, der relationale Datenbanken wie MySQL von NoSQL unterscheidet und ein wichtiges Mittel zur Gewährleistung der Datenkonsistenz darstellt. In diesem Artikel werden zunächst die Grundkonzepte im Zusammenhang mit MySQL-Transaktionen vorgestellt, dann die ACID--Eigenschaften von Transaktionen vorgestellt und deren Implementierungsprinzipien analysiert.

MySQL ist umfassend und tiefgreifend, und Auslassungen im Artikel sind unvermeidlich.

1. Grundkonzepte

Transaktion ist eine Programmausführungseinheit, die auf die Datenbank zugreift und diese aktualisiert. Eine Transaktion kann eine oder mehrere SQL-Anweisungen enthalten, die entweder ausgeführt werden , oder keines von beiden. Als relationale Datenbank unterstützt MySQL Transaktionen. Die Einführung in diesem Artikel basiert auf MySQL5.6.

Sehen Sie sich zunächst die Grundlagen von MySQL-Transaktionen an. (Empfohlener Kurs: MySQL-Video-Tutorial)

1. Logische Architektur und Speicher-Engine

Wie gezeigt oben Wie gezeigt, kann die logische Architektur des MySQL-Servers von oben nach unten in drei Schichten unterteilt werden:

(1) Die erste Schicht: verwaltet Clientverbindungen, Autorisierungsauthentifizierung usw.

(2) Die zweite Schicht: die Serverschicht, die für das Parsen, Optimieren, Zwischenspeichern von Abfrageanweisungen, die Implementierung integrierter Funktionen, gespeicherter Prozeduren usw. verantwortlich ist.

(3) Die dritte Schicht: Speicher-Engine, verantwortlich für die Speicherung und den Abruf von Daten in MySQL. Die Serverschicht in MySQL verwaltet keine Transaktionen und Transaktionen werden von der Speicher-Engine implementiert. Zu den Speicher-Engines von MySQL, die Transaktionen unterstützen, gehören InnoDB, NDB Cluster usw., wobei InnoDB am häufigsten verwendet wird. Andere Speicher-Engines wie MyIsam, Memory usw. unterstützen keine Transaktionen.

Sofern nicht anders angegeben, basieren die im folgenden Artikel beschriebenen Inhalte auf InnoDB.

2. Senden und Rollback

Eine typische MySQL-Transaktion wird wie folgt ausgeführt:

start transaction;
……  #一条或多条sql语句
commit;

Nach dem Login kopieren

wobei Starttransaktion den Start der Transaktion identifiziert, Commit die Transaktion festschreibt und schreibt die Ausführungsergebnisse in die Datenbank. Wenn bei der Ausführung von SQL-Anweisungen ein Problem auftritt, wird ein Rollback aufgerufen, um alle erfolgreich ausgeführten SQL-Anweisungen zurückzusetzen. Natürlich können Sie zum Rollback auch die Rollback-Anweisung direkt in der Transaktion verwenden.

Autocommit

MySQL verwendet standardmäßig den Autocommit-Modus, wie unten gezeigt:

Im Auto-Commit-Modus Wenn eine Transaktion nicht explizit durch Starttransaktion gestartet wird, wird jede SQL-Anweisung als Transaktion behandelt, um eine Festschreibungsoperation auszuführen.

Autocommit kann auf folgende Weise deaktiviert werden. Es ist zu beachten, dass das Ändern der Parameter in einer Verbindung keine Auswirkungen auf andere Verbindungen hat.

Wenn Autocommit deaktiviert ist, befinden sich alle SQL-Anweisungen in einer Transaktion, bis Commit oder Rollback ausgeführt wird, die Transaktion endet und eine andere Transaktion beginnt.

Spezielle Operationen

In MySQL gibt es einige spezielle Befehle, die in einer Transaktion ausgeführt werden müssen, z. B DDL-Anweisungen (Tabelle erstellen/Tabelle löschen/ändern/Tabelle), Tabellensperranweisungen usw.

Die häufig verwendeten Befehle zum Auswählen, Einfügen, Aktualisieren und Löschen erzwingen jedoch nicht das Festschreiben der Transaktion.

3. ACID-Merkmale

ACID ist ein Maß für vier Merkmale von Transaktionen:

Atomizität (oder Unteilbarkeit)
Konsistenz
Isolierung
Haltbarkeit

Nur nach strengen Standards Transaktionen, die die ACID-Merkmale erfüllen, gelten als Transaktionen. In den Implementierungen großer Datenbankanbieter gibt es jedoch nur sehr wenige Transaktionen, die tatsächlich die ACID erfüllen. Beispielsweise erfüllt die NDB-Cluster-Transaktion von MySQL nicht die Haltbarkeits- und Isolationsstufe; die Standard-Transaktionsisolationsstufe von InnoDB ist wiederholbares Lesen, was die Isolationsstufe nicht erfüllt; , mit Es heißt, dass ACID Bedingungen sind, die eine Transaktion erfüllen muss. Besser gesagt sind es die vier Dimensionen zur Messung von Transaktionen.

Die ACID-Merkmale und ihre Implementierungsprinzipien werden im Folgenden zum besseren Verständnis ausführlich vorgestellt. Die Reihenfolge der Einführung ist nicht streng A-C-I-D.

2. Atomizität

Atomizität bedeutet, dass eine Transaktion eine unteilbare Arbeitseinheit ist, in der alle Operationen ausgeführt werden Wenn die Ausführung einer SQL-Anweisung in der Transaktion fehlschlägt, muss auch die ausgeführte Anweisung zurückgesetzt werden und die Datenbank kehrt in den Zustand vor der Transaktion zurück.

2. Implementierungsprinzip: Protokoll rückgängig machen

Bevor wir das Prinzip der Atomizität erläutern, stellen wir zunächst das MySQL-Transaktionsprotokoll vor. Es gibt viele Arten von MySQL-Protokollen, z. B. Binärprotokolle, Fehlerprotokolle, Abfrageprotokolle, langsame Abfrageprotokolle usw. Darüber hinaus bietet die InnoDB-Speicher-Engine auch zwei Arten von Transaktionsprotokollen: Redo-Protokoll (Redo-Protokoll) und Rückgängig-Protokoll ( Rollback-Protokoll). Das Redo-Log wird verwendet, um die Dauerhaftigkeit der Transaktion sicherzustellen; das Undo-Log ist die Grundlage für die Atomizität und Isolation der Transaktion.

Sprechen wir über das Rückgängig-Protokoll. Der Schlüssel zum Erreichen der Atomizität besteht darin, alle erfolgreich ausgeführten SQL-Anweisungen rückgängig machen zu können, wenn die Transaktion zurückgesetzt wird. InnoDB implementiert Rollback, indem es sich auf das Rückgängig-Protokoll verlässt: Wenn eine Transaktion die Datenbank ändert, generiert InnoDB das entsprechende Rückgängig-Protokoll ; Wenn die Transaktionsausführung fehlschlägt oder ein Rollback aufgerufen wird, wodurch die Transaktion zurückgesetzt wird, können Sie die Informationen im Rückgängig-Protokoll verwenden, um die Daten auf den vorherigen Zustand zurückzusetzen Änderung.

Undo-Protokoll ist ein logisches Protokoll, das Informationen im Zusammenhang mit der SQL-Ausführung aufzeichnet. Wenn ein Rollback auftritt, führt InnoDB basierend auf dem Inhalt des Rückgängig-Protokolls das Gegenteil der vorherigen Arbeit aus: Für jede Einfügung wird während des Rollbacks ein Löschvorgang ausgeführt, für jeden Löschvorgang wird eine Einfügung während des Rollbacks ausgeführt Beim Rollback wird ein Löschvorgang ausgeführt, bei dem eine umgekehrte Aktualisierung durchgeführt wird, um die Daten wieder zu ändern.

Nehmen Sie den Aktualisierungsvorgang als Beispiel: Wenn eine Transaktion eine Aktualisierung ausführt, enthält das generierte Rückgängig-Protokoll den Primärschlüssel der geänderten Zeile (um zu wissen, welche Zeilen geändert wurden) und welche Spalten geändert wurden Geändert, und die Werte dieser Spalten vor und nach der Änderung Wert und andere Informationen können Sie diese Informationen verwenden, um die Daten beim Rollback auf den Zustand vor der Aktualisierung zurückzusetzen.

3. Haltbarkeit

1. Persistenz bedeutet, dass die Änderungen an der Datenbank dauerhaft sein sollten, sobald sie übermittelt wurden. Nachfolgende Operationen oder Ausfälle sollten keine Auswirkungen darauf haben.

2. Implementierungsprinzip: Redo-Log

Sowohl Redo-Log als auch Undo-Log gehören zum InnoDB-Transaktionslog. Lassen Sie uns zunächst über die Hintergründe der Existenz des Redo-Logs sprechen.

InnoDB ist die Speicher-Engine von MySQL und die Daten werden auf der Festplatte gespeichert. Wenn jedoch jedes Mal Festplatten-E/A erforderlich ist, um Daten zu lesen und zu schreiben, ist die Effizienz sehr gering. Zu diesem Zweck stellt InnoDB einen Cache (Pufferpool) bereit. Der Pufferpool enthält die Zuordnung einiger Datenseiten auf der Festplatte und dient als Puffer für den Zugriff auf die Datenbank: Beim Lesen von Daten aus der Datenbank werden diese zunächst ausgelesen Pufferpool. Wenn der Pufferpool nicht im Pool vorhanden ist, werden sie beim Schreiben von Daten in die Datenbank zuerst in den Pufferpool geschrieben und dann geändert Die Daten im Pufferpool werden regelmäßig auf der Festplatte aktualisiert (dieser Vorgang wird als Dirty Flushing bezeichnet).

Die Verwendung von Buffer Pool verbessert die Effizienz beim Lesen und Schreiben von Daten erheblich, bringt aber auch neue Probleme mit sich: Wenn MySQL ausfällt und die geänderten Daten im Buffer Pool nicht auf die Festplatte geleert wurden, wird dies der Fall sein Ursache Datenverlust und Transaktionsdauerhaftigkeit können nicht garantiert werden.

Um dieses Problem zu lösen, wurde das Redo-Log eingeführt: Wenn die Daten geändert werden, wird der Vorgang zusätzlich zur Änderung der Daten im Pufferpool auch im Redo-Log aufgezeichnet, wenn die Transaktion festgeschrieben wird , wird die fsync-Schnittstelle aufgerufen, um das Redo-Protokoll zum Leeren der Festplatte zu verwenden. Wenn MySQL ausfällt, können Sie die Daten im Redo-Log lesen und die Datenbank beim Neustart wiederherstellen. Das Redo-Protokoll verwendet WAL (Write-Ahead-Protokollierung, Write-Ahead-Protokoll). Alle Änderungen werden zuerst in das Protokoll geschrieben und dann im Pufferpool aktualisiert, um sicherzustellen, dass die Daten nicht aufgrund von MySQL-Ausfallzeiten verloren gehen und somit die Haltbarkeit gewährleistet ist Anforderungen.

Da Redo-Log auch das Protokoll auf die Festplatte schreiben muss, wenn die Transaktion festgeschrieben wird, warum ist es dann schneller, als die geänderten Daten im Pufferpool direkt auf die Festplatte zu schreiben (d. h. sie zu verschmutzen)? Es gibt zwei Hauptgründe:

(1) Schmutzige Reinigung ist zufällige E/A, da der Datenspeicherort, der jedes Mal geändert wird, zufällig ist, das Schreiben des Redo-Protokolls jedoch ein Anhängevorgang ist und zu sequentiellen E/A gehört.

(2) Die schmutzige Bereinigung basiert auf Datenseiten (Seite). Eine kleine Änderung auf einer Seite erfordert das Schreiben der gesamten Seite Echter Bedarf Im Schreibteil wird ungültiges IO stark reduziert.

3. Redo-Log und Binlog

Wir wissen, dass es in MySQL auch ein Binlog (Binärprotokoll) gibt, das auch Schreibvorgänge aufzeichnen und zur Datenwiederherstellung verwendet werden kann, aber im Grunde sind es beide unterschiedlich. von:

(1) Verschiedene Funktionen: Redo-Log wird für die Wiederherstellung nach einem Absturz verwendet, um sicherzustellen, dass MySQL-Ausfallzeiten die Haltbarkeit nicht beeinträchtigen; Basierend auf der Point-in-Time-Wiederherstellung von Daten wird Binlog darüber hinaus auch für die Master-Slave-Replikation verwendet.

(2) Verschiedene Ebenen: Redo Log wird von der InnoDB-Speicher-Engine implementiert, während Binlog von der MySQL-Serverschicht implementiert wird (siehe Einführung in die logische MySQL-Architektur weiter oben im Artikel) und unterstützt sowohl InnoDB als auch andere Speicher-Engines.

(3) Der Inhalt ist unterschiedlich: Das Redo-Protokoll ist ein physisches Protokoll, und der Inhalt basiert auf der Seite der Festplatte. Binlog ist ein logisches Protokoll, und der Inhalt ist ein Teil von SQL.

(4) Der Schreibzeitpunkt ist unterschiedlich: Binlog wird geschrieben, wenn die Transaktion festgeschrieben wird; der Schreibzeitpunkt des Redo-Protokolls ist relativ unterschiedlich:

除了事务提交时，还有其他刷盘时机：如master thread每秒刷盘一次redo log等，这样的好处是不一定要等到commit时刷盘，commit速度大大加快。

四、隔离性

1. 定义

与原子性、持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。隔离性是指，事务内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰。严格的隔离性，对应了事务隔离级别中的Serializable (可串行化)，但实际应用中出于性能方面的考虑很少会使用可串行化。

隔离性追求的是并发情形下事务之间互不干扰。简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可以分为两个方面：

(一个事务)写操作对(另一个事务)写操作的影响：锁机制保证隔离性
(一个事务)写操作对(另一个事务)读操作的影响：MVCC保证隔离性

2. 锁机制

首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个事务对数据进行写操作，InnoDB通过锁机制来保证这一点。

锁机制的基本原理可以概括为：事务在修改数据之前，需要先获得相应的锁；获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。

行锁与表锁

按照粒度，锁可以分为表锁、行锁以及其他位于二者之间的锁。表锁在操作数据时会锁定整张表，并发性能较差；行锁则只锁定需要操作的数据，并发性能好。但是由于加锁本身需要消耗资源(获得锁、检查锁、释放锁等都需要消耗资源)，因此在锁定数据较多情况下使用表锁可以节省大量资源。MySQL中不同的存储引擎支持的锁是不一样的，例如MyIsam只支持表锁，而InnoDB同时支持表锁和行锁，且出于性能考虑，绝大多数情况下使用的都是行锁。

如何查看锁信息

有多种方法可以查看InnoDB中锁的情况，例如：

select * from information_schema.innodb_locks; #锁的概况
show engine innodb status; #InnoDB整体状态，其中包括锁的情况

Nach dem Login kopieren

下面来看一个例子：

#在事务A中执行：
start transaction;
update account SET balance = 1000 where id = 1;
#在事务B中执行：
start transaction;
update account SET balance = 2000 where id = 1;

Nach dem Login kopieren

此时查看锁的情况：

show engine innodb status查看锁相关的部分：

通过上述命令可以查看事务24052和24053占用锁的情况；其中lock_type为RECORD，代表锁为行锁(记录锁)；lock_mode为X，代表排它锁(写锁)。

除了排它锁(写锁)之外，MySQL中还有共享锁(读锁)的概念。由于本文重点是MySQL事务的实现原理，因此对锁的介绍到此为止，后续会专门写文章分析MySQL中不同锁的区别、使用场景等，欢迎关注。

介绍完写操作之间的相互影响，下面讨论写操作对读操作的影响。

3. 脏读、不可重复读和幻读

首先来看并发情况下，读操作可能存在的三类问题：

（1）脏读：当前事务(A)中可以读到其他事务(B)未提交的数据（脏数据），这种现象是脏读。举例如下（以账户余额表为例）：

（2）不可重复读：在事务A中先后两次读取同一个数据，两次读取的结果不一样，这种现象称为不可重复读。脏读与不可重复读的区别在于：前者读到的是其他事务未提交的数据，后者读到的是其他事务已提交的数据。举例如下：

（3）幻读：在事务A中按照某个条件先后两次查询数据库，两次查询结果的条数不同，这种现象称为幻读。不可重复读与幻读的区别可以通俗的理解为：前者是数据变了，后者是数据的行数变了。举例如下：

4. 事务隔离级别

SQL标准中定义了四种隔离级别，并规定了每种隔离级别下上述几个问题是否存在。一般来说，隔离级别越低，系统开销越低，可支持的并发越高，但隔离性也越差。隔离级别与读问题的关系如下：

In tatsächlichen Anwendungen kann Read Uncommitted viele Probleme während der Parallelität verursachen, aber die Leistungsverbesserung ist im Vergleich zu anderen Isolationsstufen sehr begrenzt, sodass es weniger verwendet wird. SerialisierbarDa die Parallelitätseffizienz erzwungen wird, ist sie sehr gering. Sie kann nur verwendet werden, wenn die Anforderungen an die Datenkonsistenz extrem hoch sind und keine Parallelität akzeptabel ist, weshalb sie selten verwendet wird. Daher ist in den meisten Datenbanksystemen die Standardisolationsstufe Read Committed ( wie Oracle) oder Repeatable Read (im Folgenden als RR).

Sie können die globale Isolationsstufe und die Isolationsstufe dieser Sitzung über die folgenden zwei Befehle anzeigen:

InnoDB Die Standardisolationsstufe ist RR, und wir werden uns später auf RR konzentrieren. Es ist zu beachten, dass RR im SQL-Standard das Phantomleseproblem nicht vermeiden kann, das von InnoDB implementierte RR jedoch das Phantomleseproblem vermeidet.

5. MVCC

RR löst Probleme wie Dirty Reads, nicht wiederholbare Lesevorgänge und Phantom Reads. Es verwendet MVCC: MVCC steht für Multi-Version Concurrency Control, eine Multiversion. Versions-Parallelitätskontrollprotokoll. Das folgende Beispiel spiegelt die Eigenschaften von MVCC gut wider: Gleichzeitig können die von verschiedenen Transaktionen gelesenen Daten unterschiedlich sein (d. h. mehrere Versionen) – zum Zeitpunkt T5 können Transaktion A und Transaktion C unterschiedliche Versionen lesen.

Der größte Vorteil von MVCC besteht darin, dass das Lesen nicht gesperrt ist, sodass es keinen Konflikt zwischen Lesen und Schreiben gibt und die Parallelitätsleistung gut ist. InnoDB implementiert MVCC, und mehrere Versionen von Daten können nebeneinander existieren, wobei sie sich hauptsächlich auf die verborgenen Datenspalten (auch Markierungsbits genannt) und das Rückgängig-Protokoll verlassen. Zu den ausgeblendeten Spalten der Daten gehören die Versionsnummer der Datenzeile, der Löschzeitpunkt, der Zeiger auf das Rückgängig-Protokoll usw. Beim Lesen der Daten kann MySQL anhand der ausgeblendeten Spalten ermitteln, ob ein Rollback erforderlich ist, und das ermitteln Für das Rollback ist ein Rückgängig-Protokoll erforderlich. Daher wird das detaillierte Format versteckter Spalten nicht mehr erweitert.

Das Folgende wird anhand der verschiedenen oben genannten Probleme separat erläutert.

(1) Dirty Read

Wenn Transaktion A Zhangsans Kontostand am T3-Zeitknoten liest, wird festgestellt, dass die Daten von anderen geändert wurden Transaktionen und der Status ist Nicht festgeschrieben. Zu diesem Zeitpunkt führt Transaktion A, nachdem sie die neuesten Daten gelesen hat, einen Rollback-Vorgang basierend auf dem Rückgängig-Protokoll der Daten durch und ruft die Daten ab, bevor Transaktion B sie geändert hat, wodurch fehlerhafte Lesevorgänge vermieden werden.

(2) Nicht wiederholbares Lesen

Wenn Transaktion A zum ersten Mal Daten auf dem T2-Knoten liest, wird die Versionsnummer der Daten (Daten) angezeigt Die Versionsnummer wird in Zeileneinheiten aufgezeichnet. Unter der Annahme, dass die Versionsnummer 1 ist, erhöht sich die in dieser Zeile aufgezeichnete Versionsnummer unter der Annahme, dass die Versionsnummer 2 ist, wenn Transaktion A bei T5 erneut Daten liest dass die Versionsnummer der Daten (2) größer ist als die Versionsnummer (1), die beim ersten Lesen aufgezeichnet wurde. Daher wird ein Rollback-Vorgang basierend auf dem Rückgängig-Protokoll durchgeführt, um die Daten zu erhalten, wenn die Versionsnummer 1 ist. Dadurch wird eine wiederholbare Lesung erreicht.

(3) Phantomlesen

Das von InnoDB implementierte RR vermeidet das Phänomen des Phantomlesens durch den Next-Key-Sperrmechanismus.

Nächste-Tasten-Sperre ist eine Art Zeilensperre und ihre Implementierung entspricht der Datensatzsperre (Datensatzsperre) + Lückensperre (Lückensperre); Sein Merkmal ist, dass es nicht nur den Datensatz selbst sperrt (die Funktion der Datensatzsperre), sondern auch einen Bereich sperrt (Lückensperre Funktion). Natürlich geht es hier um entsperrtes Lesen: Die Next-Key-Sperre ist zu diesem Zeitpunkt nicht wirklich gesperrt, sie fügt lediglich eine Markierung zu den gelesenen Daten hinzu (der Markierungsinhalt umfasst die Versionsnummer der Daten, usw.); genau Aus diesem Grund nennen wir es einen Next-Key-Sperrmechanismus. Lassen Sie uns das vorherige Beispiel zur Veranschaulichung verwenden:

Wenn Transaktion A zum ersten Mal 0

6. Zusammenfassung

Zusammenfassend lässt sich sagen, dass die von InnoDB implementierte RR durch den Sperrmechanismus, versteckte Datenspalten, Rückgängig-Protokoll und die Sperrklasse für den nächsten Schlüssel ein gewisses Maß an Isolation erreichen kann die bedürfnisse der meisten szenarien. Es ist jedoch zu beachten, dass RR zwar das Phantomleseproblem vermeidet, aber dennoch nicht serialisierbar ist und keine vollständige Isolation garantieren kann. Hier ist ein Beispiel, das Sie selbst überprüfen können.

5. Konsistenz

1. Grundkonzept

Konsistenz bedeutet, dass nach Abschluss der Transaktionsausführung die Integritätsbeschränkungen der Datenbank nicht zerstört werden Die Datenbank wird vor und nach der Transaktionsausführung nicht zerstört. Zu den Integritätsbeschränkungen der Datenbank gehören unter anderem: Entitätsintegrität (z. B. der Primärschlüssel der Zeile ist vorhanden und eindeutig), Spaltenintegrität (z. B. Typ, Größe und Länge des Felds müssen erfüllt sein). Anforderungen), Fremdschlüsseleinschränkungen und benutzerdefinierte Vollständigkeit (z. B. sollte die Summe der Salden der beiden Konten vor und nach der Übertragung unverändert bleiben).

2. Implementierung

Man kann sagen, dass Konsistenz das ultimative Ziel von Transaktionen ist: Die oben erwähnte Atomizität, Persistenz und Isolation sollen die Konsistenz des Datenbankstatus sicherstellen. Darüber hinaus erfordert die Umsetzung der Konsistenz neben Garantien auf Datenbankebene auch Garantien auf Anwendungsebene.

Maßnahmen zur Erreichung der Konsistenz umfassen:

Garantie der Atomizität, Haltbarkeit und Isolation. Wenn diese Eigenschaften nicht garantiert werden können, kann auch die Konsistenz der Transaktion nicht garantiert werden
Die Datenbank selbst bietet Garantien, zum Beispiel ist es nicht erlaubt, String-Werte in ganzzahlige Spalten einzufügen, die String-Länge darf das Spaltenlimit nicht überschreiten usw.
Wird auf Anwendungsebene durchgeführt. Garantiert beispielsweise die Konsistenz des Status, wenn der Überweisungsvorgang nur den Saldo des Übertragenden abzieht und den Saldo des Empfängers nicht erhöht, egal wie perfekt die Datenbank implementiert ist kann nicht garantiert werden

6. Zusammenfassung

Im Folgenden werden die ACID-Merkmale und ihre Implementierungsprinzipien zusammengefasst:

Atomizität: Aussagen werden entweder vollständig ausgeführt oder überhaupt nicht ausgeführt. Die Transaktion selbst wird durch Atomizität definiert. Die Implementierung basiert hauptsächlich auf dem Rückgängigmachen-Protokoll.
Persistenz: um sicherzustellen, dass Daten aufgrund von Ausfallzeiten und anderen Gründen nach der Transaktionseinreichung nicht verloren gehen; die Implementierung basiert hauptsächlich auf dem Redo-Log
Isolierung: Stellen Sie sicher, dass die Transaktionsausführung nicht durch andere Transaktionen beeinträchtigt wird So viel wie möglich; Die Standardisolationsstufe von InnoDB ist RR. Die Implementierung von RR basiert hauptsächlich auf dem Sperrmechanismus, versteckten Datenspalten, dem Rückgängig-Protokoll und dem Klassen-Next-Key-Sperrmechanismus
Konsistenz: Das ultimative Ziel von Transaktionen. Die Verwirklichung der Konsistenz erfordert sowohl Garantien auf Datenbankebene als auch Garantien auf Anwendungsebene

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in das Implementierungsprinzip der ACID-Merkmale von MySQL-Transaktionen (Bild und Text). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!