ACID-Eigenschaften von MySQL-Transaktionen (ausführliche Erklärung)

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.

1. Grundkonzepte

Transaktion dient dem Zugriff und der Aktualisierung der Datenbank. Programmausführung Einheit; eine Transaktion kann eine oder mehrere SQL-Anweisungen enthalten, die entweder alle oder keine ausgeführt werden. 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.

1. Logische Architektur und Speicher-Engine

Bildquelle: https://blog.csdn .net/fuzhongmin05/article/details/70904190

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

(1) Die erste Schicht: Verarbeitung der Terminalverbindung des Kunden, Autorisierungsauthentifizierung usw.

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

(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. Commit und Rollback

Eine typische MySQL-Transaktion funktioniert wie folgt:

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

Starttransaktion identifiziert den Start der Transaktion, Commit schreibt die Transaktion fest 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.

Sie können Autocommit auf folgende Weise deaktivieren. Beachten Sie, 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 (Konsistenz)
• Isolation (Isolation)
• Dauerhaftigkeit (Durability)

Befolgen Sie strenge Standards, nur Transaktionen, die Transaktionen, die gleichzeitig die ACID-Merkmale erfüllen, werden als Transaktionen betrachtet. In den Implementierungen großer Datenbankanbieter gibt es jedoch nur sehr wenige Transaktionen, die tatsächlich 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

1. Atomcharakteristik bedeutet, dass eine Transaktion eine unteilbare Arbeitseinheit ist, in der Vorgänge entweder ausgeführt werden oder nicht. Wenn eine SQL-Anweisung in der Transaktion nicht ausgeführt werden kann, muss auch die ausgeführte Anweisung zurückgesetzt werden und die Datenbank kehrt in den Zustand vor der Transaktion zurück . Zustand.

2. Umsetzungsprinzip: Protokoll rückgängig machen

Bevor wir das Prinzip der Atomizität erklären, 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 stellt die InnoDB-Speicher-Engine auch zwei Transaktionsprotokolle bereit: Redo-Protokoll (Redo-Protokoll) und Rückgängig-Protokoll (Rollback-Protokoll). ). Das Redo-Log wird verwendet, um die Haltbarkeit 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. Persistenz

1. Persistenz-Sex bedeutet, dass die Änderungen an der Datenbank dauerhaft sein sollten, sobald eine Transaktion festgeschrieben wurde. 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 (Buffer Pool) bereit. Der Buffer Pool 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) Die schmutzige Reinigung ist eine zufällige E/A, da der Datenspeicherort, der jedes Mal geändert wird, zufällig ist, das Schreiben des Redo-Protokolls jedoch eine Anhängeoperation ist und zur 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 kann und für die Datenwiederherstellung verwendet werden, aber die beiden unterscheiden sich grundlegend: (1) Unterschiedliche Funktionen: Redo-Log wird für die Absturzwiederherstellung verwendet, um sicherzustellen, dass MySQL-Ausfallzeiten die Haltbarkeit nicht beeinträchtigen. Binlog wird für die Absturzwiederherstellung verwendet Die rechtzeitige Wiederherstellung stellt sicher, dass der Server Daten basierend auf Zeitpunkten wiederherstellen kann. Darüber hinaus wird Binlog 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: Redo-Log ist ein physisches Protokoll, und der Inhalt von binlog ist binär. Abhängig vom Parameter binlog_format kann er auf SQL-Anweisungen basieren , die Daten selbst oder eine Mischung aus beiden.

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

• 前面曾提到：当事务提交时会调用fsync对redo log进行刷盘；这是默认情况下的策略，修改innodb_flush_log_at_trx_commit参数可以改变该策略，但事务的持久性将无法保证。
• 除了事务提交时，还有其他刷盘时机：如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整体状态，其中包括锁的情况

下面来看一个例子：

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

此时查看锁的情况：

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

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

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

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

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

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

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

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

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

4. Transaktionsisolationsstufe

Der SQL-Standard definiert vier Isolationsstufen und legt fest, ob die oben genannten Probleme unter jeder Isolationsstufe bestehen. Im Allgemeinen gilt: Je niedriger die Isolationsstufe, desto geringer ist der Systemaufwand, desto höher ist die unterstützte Parallelität, aber desto schlechter ist die Isolation. Die Beziehung zwischen Isolationsstufe und Leseproblemen ist wie folgt:

In tatsächlichen Anwendungen verursacht nicht festgeschriebenes Lesen viele Probleme bei der Parallelität und die Leistung ist relativ Andere Verbesserungen der Isolationsstufe sind begrenzt und werden daher weniger häufig verwendet. 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 Reads, Phantom Reads usw. Es verwendet MVCC: the Der vollständige Name von MVCC ist Multi-Version Concurrency Control, ein Protokoll zur Steuerung der Parallelität mehrerer Versionen. 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 versteckten Datenspalten (auch Markierungsbits genannt) und das Rückgängig-Protokoll verlassen. Zu den ausgeblendeten Spalten der Daten gehören die Versionsnummer der Datenzeile, die Löschzeit, der Zeiger auf das Rückgängig-Protokoll usw.; beim Lesen der Daten kann MySQL die ausgeblendeten Spalten verwenden, um zu bestimmen, ob ein Rollback erforderlich ist, und das zu finden Für das Rollback ist ein Rückgängig-Protokoll erforderlich. Daher wird das detaillierte Format versteckter Spalten nicht mehr erweitert.

Das Folgende wird im Zusammenhang mit den verschiedenen oben genannten Problemen 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, vorausgesetzt, die Versionsnummer ist 2, 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 Der Einfachheit halber 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, das Rückgängig-Protokoll und die Sperre für den nächsten Schlüssel ein gewisses Maß an Isolation erreicht, was den Anforderungen der meisten Szenarien gerecht werden kann. 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. Grundkonzepte

Konsistenz bedeutet, dass nach Ausführung der Transaktion

die Integritätsbeschränkungen der Datenbank nicht zerstört werden und der Datenstatus vor und nach Ausführung der Transaktion legal ist. 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. Umsetzung

Man kann sagen, dass Konsistenz das ultimative Ziel ist, das von Transaktionen verfolgt wird: die zuvor erwähnte Atomizität, Haltbarkeit und Isolation , alles um die Konsistenz des Datenbankstatus sicherzustellen. Darüber hinaus erfordert die Umsetzung der Konsistenz neben Garantien auf Datenbankebene auch Garantien auf Anwendungsebene.

Maßnahmen zur Erreichung der Konsistenz umfassen:

Gewährleistung von Atomizität, Haltbarkeit und Isolation. Wenn diese Eigenschaften nicht garantiert werden können, kann auch die Transaktionskonsistenz nicht garantiert werden
• Die Datenbank selbst bietet Garantien, zum Beispiel ist es nicht erlaubt, String-Werte in Integer-Spalten einzufügen, die String-Länge darf das Spaltenlimit nicht überschreiten usw.
• Garantien werden auf Anwendungsebene bereitgestellt, zum Beispiel wenn die Der Übertragungsvorgang zieht nur den Saldo des Übertragenden ab, nicht jedoch die Erhöhung des Saldos des Empfängers, egal wie perfekt die Datenbank implementiert ist, kann keinen konsistenten Zustand garantieren

6. Zusammenfassung

Das Folgende Fasst die ACID-Merkmale und ihre Implementierungsprinzipien zusammen:

• Atomizität: Anweisungen werden entweder vollständig ausgeführt oder überhaupt nicht ausgeführt Kernmerkmal einer Transaktion. Die Transaktion selbst wird durch Atomizität definiert. Die Implementierung basiert hauptsächlich auf dem Rückgängigmachen-Protokoll Gründe nach der Übermittlung der Transaktion; die Implementierung basiert hauptsächlich auf Redo-Log

Stellen Sie sicher, dass die Transaktionsausführung nicht so stark wie möglich von anderen Transaktionen beeinflusst wird von RR basiert hauptsächlich auf dem Sperrmechanismus, versteckten Datenspalten, dem Rückgängig-Protokoll und dem Next-Key-Sperrmechanismus

• Konsistenz: Das von Transaktionen verfolgte Endziel erfordert Garantien auf beiden Seiten Datenbankebene und Anwendungsebene
• Empfohlenes Lernen:

  MySQL-Tutorial

Das obige ist der detaillierte Inhalt vonACID-Eigenschaften von MySQL-Transaktionen (ausführliche Erklärung). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!