MySQL-Transaktionsdetails

Atomarität:
	Entweder sind alle erfolgreich oder alle schlagen fehl. Das Undo-Log sorgt für Konsistenz:
	Beispielsweise bleibt die Summe der beiden Beträge vor und nach der Überweisung unverändert. Isolation: Die Datenbank bietet einen bestimmten Isolationsmechanismus, um sicherzustellen, dass die Transaktion in einer „unabhängigen“ Umgebung ausgeführt wird, die nicht von externen gleichzeitigen Vorgängen beeinflusst wird. Sperre, MVCC-Mehrversions-Parallelitätskontrolle. Dauerhaft: Die Transaktionsübermittlung bleibt im Redo-Protokoll der Festplatte erhalten

Dirty Reads (Dirty Reads) Eine Transaktion greift auf nicht festgeschriebene Daten einer anderen Transaktion zu:
	Wenn eine Transaktion auf Daten zugreift und diese ändert und diese Änderung noch nicht in der Datenbank übernommen wurde, greift eine andere Transaktion ebenfalls auf die Daten zu und verwendet sie dann.
Nicht wiederholbare Lesevorgänge (eine Transaktion führt die gleiche Abfrage zweimal aus, erhält aber unterschiedliche Daten):
	Eine Transaktion liest einige Daten und liest dann die Daten, die sie zuvor gelesen hat. Sie stellt fest, dass die Daten nicht mit den Daten übereinstimmen, die sie zuvor gelesen hat. Phantom-Lesevorgänge aktualisieren und löschen (eine Transaktion führt dieselbe Abfrage zweimal durch und erhält unterschiedliche Daten):
	Eine Transaktion liest zuvor abgefragte Daten gemäß denselben Abfragebedingungen erneut, stellt jedoch fest, dass andere Transaktionen neue Daten eingefügt haben, die ihre Abfragebedingungen erfüllen.

Legen Sie die Transaktionsisolationsstufe A, B fest.
	Legen Sie die Isolationsebene für Sitzungstransaktionen fest und lesen Sie nicht fest.
SitzungA
Transaktion starten, Transaktion starten;
Fügen Sie Daten ein: INSERT INTO `db_test`.`t_user`(`id`, `name`) VALUES (5, 'DuQi');
SitzungB
Eine andere Verbindungsabfrage lautet „select * from t_user“.
	+----+----------+
	| Ich würde | Name |
	+----+----------+
	| 1 | ZhangSan |
	| 2 | LiSi |
	| 3 | WangWu |
	| 4 | Lao Wang |
	| 5 | DuQi |
	+----+----------+
	Zu diesem Zeitpunkt fragt Verbindung B die Datensatz-ID der nicht festgeschriebenen Transaktion von Verbindung A ab, die 5 ist.
	
Hier überprüfen wir, ob eine Sitzung nicht festgeschriebene Daten aus einer anderen Transaktion gelesen hat.

Ändern Sie die Isolationsebene der Transaktionen, legen Sie die Isolationsebene der Sitzungstransaktionen fest und lesen Sie fest.
A startet eine Transaktion, Starttransaktion;
Überprüfen Sie, ob das Update B die Abfrageanweisung MySQL [db_test]> select * from t_user; ausführt.
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		| 5 | DuQi |
		+----+----------+
	A führt die Update-Anweisung update t_user set name = 'duqi' where id = 5; aus.
	B führt die Abfrageanweisung „Starttransaktion“ aus;
		MySQL [db_test]> wähle * von t_user;
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		| 5 | DuQi |
		+----+----------+
	A führt das Transaktions-Commit aus.
	B führt die Abfrageanweisung aus (die Ergebnisse zweier Abfragen für dieselbe Transaktion sind inkonsistent)
		MySQL [db_test]> wähle * von t_user;
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		| 5 | duqi |
		+----+----------+
Fahren Sie mit der Überprüfung des Löschvorgangs fort. A startet eine Transaktion. B startet eine Transaktion. Transaktion starten;
	A löscht einen Datensatz aus t_user, wobei ID = 5 ist.
	Die Abfrage der Transaktion B ist normal und die gelöschten Datensätze sind immer noch in MySQL [db_test]> select * from t_user;
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		| 5 | DuQi |
		+----+----------+
	Ein Commit;
	B fragt weiter ab und stellt fest, dass die Ergebnisse mehrerer Abfragen derselben Transaktion inkonsistent sind. MySQL [db_test]> select * from t_user;
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		+----+----------+

Überprüfen Sie das Einfügen von A und B. Starten Sie die Transaktion. Starten Sie die Transaktion.
	A fügt Datensätze ein INSERT INTO `db_test`.`t_user`(`id`, `name`) VALUES (5, 'DuQi');
	B-Abfragen MySQL [db_test]> select * from t_user;
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		+----+----------+	
	A führt das Transaktions-Commit aus.
	B-Abfrage kann auch die von A übermittelte Transaktion abfragen MySQL [db_test]> select * from t_user;
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		| 5 | DuQi |
		+----+----------+

Ändern Sie die Transaktionsisolationsebene, legen Sie die Transaktionsisolationsebene für Sitzungen fest und ermöglichen Sie wiederholbares Lesen.
A und B starten Transaktion, starten Transaktion;
A fügt ein Datenelement ein	
	INSERT INTO `db_test`.`t_user`(`id`, `name`) VALUES (5, 'DuQi');
B MySQL-Abfrage [db_test]> select * from t_user;
	+----+----------+
	| Ich würde | Name |
	+----+----------+
	| 1 | ZhangSan |
	| 2 | LiSi |
	| 3 | WangWu |
	| 4 | Lao Wang |
	+----+----------+
A führt das Transaktions-Commit aus.
B Transaktionsabfrage MySQL [db_test]> select * from t_user;
	+----+----------+
	| Ich würde | Name |
	+----+----------+
	| 1 | ZhangSan |
	| 2 | LiSi |
	| 3 | WangWu |
	| 4 | Lao Wang |
	| 5 | DuQi |
	+----+----------+
Es kann sein, dass zwischen verschiedenen Transaktionen die Einfügung abgefragt werden kann. Lassen Sie uns weiterhin das Aktualisieren und Löschen überprüfen. A und B starten die Transaktion. A aktualisiert das Update t_user set name = 'duqi' where id = 5;
	B MySQL-Abfrage [db_test]> select * from t_user;
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		| 5 | DuQi |
		+----+----------+	
	A führt die Transaktion aus
	B fährt mit der MySQL-Abfrage fort [db_test]> select * from t_user;
		+----+----------+
		| Ich würde | Name |
		+----+----------+
		| 1 | ZhangSan |
		| 2 | LiSi |
		| 3 | WangWu |
		| 4 | Lao Wang |
		| 5 | DuQi |
		+----+----------+
	Lassen Sie uns mit der Überprüfung des Löschvorgangs fortfahren. A und B starten Transaktionen. Transaktion A führt den Löschvorgang „delete from t_user where id = 5“ aus.
		Transaktion B führt die Abfrage MySQL [db_test]> select * from t_user; aus.
			+----+----------+
			| Ich würde | Name |
			+----+----------+
			| 1 | ZhangSan |
			| 2 | LiSi |
			| 3 | WangWu |
			| 4 | Lao Wang |
			| 5 | duqi |
			+----+----------+
		A führt die Transaktion aus und B fährt mit der MySQL-Abfrage fort [db_test]> select * from t_user;
			+----+----------+
			| Ich würde | Name |
			+----+----------+
			| 1 | ZhangSan |
			| 2 | LiSi |
			| 3 | WangWu |
			| 4 | Lao Wang |
			| 5 | duqi |
			+----+----------+
Möglicherweise stellen Sie fest, dass die Transaktionsisolationsebene REPEATABLE-READ die Probleme beim Löschen und Aktualisieren löst, das Problem beim Einfügen jedoch weiterhin besteht.

Die Implementierung von mvcc in MySQL INNODB dient hauptsächlich dazu, die gleichzeitige Leistung der Datenbank zu verbessern und Lese-/Schreibkonflikte besser zu handhaben, sodass auch bei Lese-/Schreibkonflikten ein gleichzeitiges Lesen ohne Sperren und Blockieren erreicht werden kann.

Vorgänge wie die Auswahlsperre im Freigabemodus (gemeinsame Sperre), die Auswahl zum Aktualisieren, Aktualisieren, Einfügen, Löschen (exklusive Sperre) sind alles aktuelle Lesevorgänge.
Warum heißt es „Aktueller Messwert“?
	Das heißt, es liest die neueste Version des Datensatzes. Beim Lesen muss sichergestellt werden, dass andere gleichzeitige Transaktionen den aktuellen Datensatz nicht ändern können und der gelesene Datensatz gesperrt wird.

Beispielsweise handelt es sich bei einem entsperrten Auswahlvorgang um einen Snapshot-Lesevorgang, also einen nicht blockierenden Lesevorgang ohne Sperrung.
Voraussetzung für das Lesen von Snapshots ist, dass die Isolationsebene nicht die serielle Ebene ist. Das Lesen von Snapshots auf serieller Ebene degeneriert zum aktuellen Lesen.
Der Grund für das Lesen von Snapshots besteht darin, die Parallelitätsleistung zu verbessern. Die Implementierung von Snapshots basiert auf der Multiversion-Parallelitätssteuerung, nämlich MVCC. MVCC kann als eine Variante der Zeilensperre betrachtet werden, vermeidet jedoch in vielen Fällen Sperrvorgänge und reduziert den Overhead.

Die MVCC-Mehrversions-Parallelitätskontrolle bezieht sich auf die Verwaltung mehrerer Versionen von Daten, sodass es bei Lese- und Schreibvorgängen zu keinen Konflikten kommt. Snapshot Read ist eine nicht blockierende Lesefunktion von MySQL zur Implementierung von MVCC.
Die spezifische Implementierung des MVCC-Moduls in MySQL wird durch drei implizite Felder, Undo-Protokolle und Readview-Komponenten implementiert.

1. Lesen/Lesen: Es gibt kein Problem und es ist keine Parallelitätskontrolle erforderlich. 2. Lesen/Schreiben: Es gibt Thread-Sicherheitsprobleme, die Probleme mit der Transaktionsisolationsebene verursachen können und zu Dirty Reads, nicht wiederholbaren Lesevorgängen und Phantom-Lesevorgängen führen können. 3. Schreiben/Schreiben: Es gibt Thread-Sicherheitsprobleme und es können Probleme mit Updateverlusten auftreten.

1. Beim gleichzeitigen Lesen und Schreiben in der Datenbank ist es möglich, dies zu tun, ohne den Schreibvorgang während des Lesevorgangs zu blockieren, und der Schreibvorgang muss den Lesevorgang nicht blockieren, wodurch die Leistung beim gleichzeitigen Lesen und Schreiben in der Datenbank verbessert wird. 2. Es löst Transaktionsisolierungsprobleme wie Dirty Reads, Phantom Reads und nicht wiederholbare Lesevorgänge, kann jedoch das Problem des Aktualisierungsverlusts nicht lösen.

DB_TRX_ID Zuletzt geänderte Transaktions-ID:
	6 Bytes, zeichnet die Transaktions-ID auf, die diesen Datensatz erstellt oder zuletzt geändert hat
DB_ROLL_PTR Rollback-Zeiger:
	7 Bytes, die auf die vorherige Version dieses Datensatzes verweisen und zur Zusammenarbeit mit Undolog verwendet werden. Sie verweisen auf den versteckten Primärschlüssel DB_ROW_ID der vorherigen alten Version:
	6 Bytes. Wenn die Datenbanktabelle keinen Primärschlüssel hat, generiert InnoDB automatisch eine 6-Byte-Zeilen-ID.

Beim Ausführen von Einfügevorgängen wird das generierte Undo-Protokoll nur benötigt, wenn die Transaktion zurückgesetzt wird, und kann sofort nach dem Festschreiben der Transaktion verworfen werden. Beim Ausführen von Aktualisierungs- und Löschvorgängen wird das generierte Undo-Protokoll nicht nur benötigt, wenn die Transaktion zurückgesetzt wird, sondern auch, wenn der Snapshot gelesen wird, sodass es nicht beiläufig gelöscht werden kann. Nur wenn das Lesen des Snapshots oder das Zurücksetzen der Transaktion das Protokoll nicht betrifft, wird das entsprechende Protokoll vom Bereinigungsthread gleichmäßig gelöscht (wenn Daten aktualisiert oder gelöscht werden, wird nur der alte Datensatz festgelegt. Wenn die Deleted_ID eines Datensatzes wahr ist und DB_TRX_ID für die Leseansicht des Bereinigungsthreads sichtbar ist, kann dieser Datensatz definitiv gelöscht werden).

Beim Ausführen eines Einfügevorgangs wird eine entsprechende Löschanweisung generiert. Beim Ausführen eines Löschvorgangs wird die Einfügeanweisung der Originaldaten gesichert. Beim Ausführen einer Aktualisierung wird die Aktualisierungsanweisung der Originaldaten aufgezeichnet. Dieser Vorgang ist praktisch für das Zurücksetzen von Datensätzen.

Die größte Funktion der Lesung ist die Beurteilung von Sichtbarkeiten. Um die db_trx_id im neuesten Datensatz der zu modifizierenden Daten herauszunehmen, und mit der ID anderer aktiver Transaktionen im System zu vergleichen. B_TRX_ID, das den Bedingungen erfüllt, wird gefunden.

trx_liste:
	Eine Liste von Werten, die zur Pflege der Transaktions-IDs verwendet werden, die zum Zeitpunkt der Generierung der Leseansicht im System aktiv sind
up_limit_id:
	Notieren Sie die Mindest-ID der Transaktions-ID in der Liste trx_list
Untergrenze-ID:
	Das System hat die nächste Transaktions-ID noch nicht zugeordnet, wenn die Leseansicht generiert wird

1. Bestimmen Sie zunächst, ob DB_TRX_ID < up_limit_id ist. Wenn es kleiner als up_limit_id ist, kann die aktuelle Transaktion den Datensatz sehen, in dem sich DB_TRX_ID befindet. Wenn es größer oder gleich ist, fahren Sie mit der nächsten Bestimmung fort. 2. Bestimmen Sie, ob DB_TRX_ID >= low_limit_id ist. Wenn es größer oder gleich ist, bedeutet dies, dass der Datensatz, in dem sich DB_TRX_ID befindet, erst nach der Generierung der Lese-Ansicht erscheint und daher für die aktuelle Transaktion definitiv nicht sichtbar ist. Wenn es kleiner als ist, fahren Sie mit der nächsten Bestimmung fort. 3. Bestimmen Sie, ob sich DB_TRX_ID in einer aktiven Transaktion befindet. Wenn dies der Fall ist, bedeutet dies, dass diese Transaktion zum Zeitpunkt der Generierung der Lese-Ansicht noch aktiv ist und nicht festgeschrieben wurde. Die geänderten Daten können von der aktuellen Transaktion nicht gesehen werden. Wenn dies nicht der Fall ist, bedeutet dies, dass diese Transaktion vor der Generierung der Lese-Ansicht festgeschrieben wurde, sodass das geänderte Ergebnis angezeigt werden kann.