Anfänger verstehen das MySQL-Deadlock-Problem anhand des Quellcodes

Nach vielen schwierigen Einzelschritt-Debuggings spät in der Nacht habe ich endlich einen idealen Haltepunkt gefunden. Ich kann sehen, dass der Großteil des Codes für den Sperrenerwerbsprozess in der static enum db_err lock_rec_lock() Funktion von lock0lock.c enthalten ist. Diese Funktion zeigt den Prozess des Sperrenerwerbs an und zeigt an, ob der Sperrenerwerb erfolgreich war oder nicht.

Szenario 1: Löschen nach Primärschlüssel

Tabellenstruktur

TABELLE ERSTELLEN `t1` (
 `id` int(11) NICHT NULL AUTO_INCREMENT,
 `name` varchar(10) NICHT NULL STANDARD '',
 PRIMÄRSCHLÜSSEL (`id`)
)ENGINE=InnoDB;

Löschen Sie aus t1, wo ID = 10;

Wie Sie sehen, ist der Index PRIMARY gesperrt, Modus = 1027. Was bedeutet 1027? 1027 = LOCK_REC_NOT_GAP + LOCK_X (Non-Gap-Datensatzsperre und X-Sperre)

Der Ablauf ist wie folgt

Fazit: Um Daten basierend auf der Primärschlüssel-ID und ohne andere Indizes zu löschen, muss diese SQL-Anweisung nur eine X-Sperre zum Primärschlüsselindex des Datensatzes mit der ID = 10 hinzufügen.

Szenario 2: Löschen über einen eindeutigen Index

Die Tabellenstruktur wurde leicht angepasst und ein eindeutiger Namensindex hinzugefügt.

Daten konstruieren CREATE TABLE `t2` (
 `id` int(11) NICHT NULL AUTO_INCREMENT,
 `name` varchar(10) NICHT NULL STANDARD '',
 Primärschlüssel (`id`),
 EINZIGARTIGER SCHLÜSSEL `uk_name` (`name`)
) ;
WERTE IN `t2` (`id`, `name`) EINFÜGEN 
 (1,'M'),
 (2,'J'),
 (3,'S'),
 (4,'Q'),
 (5,'L');
 
Testen Sie die SQL-Anweisung „Löschen von t2“, wobei Name = „Y“ ist.

Schauen wir uns die Ergebnisse des tatsächlichen Quellcode-Debuggings an

Erster Schritt:

Schritt 2:

Fazit: Dieser Prozess fügt zuerst eine X-Sperre zum eindeutigen Schlüssel uk_name und dann eine X-Sperre zum Clustered-Index (Primärschlüsselindex) hinzu.

Der Ablauf ist wie folgt

Szenario 3: Löschen über einen normalen Index

Daten konstruieren CREATE TABLE `t3` (
 `id` int(11) NICHT NULL AUTO_INCREMENT,
 `name` varchar(10) NICHT NULL STANDARD '',
 Primärschlüssel (`id`),
 SCHLÜSSEL `idx_name` (`Name`) 
);
WERTE IN `t3` (`id`, `name`) EINFÜGEN 
 (1,'N'),
 (2,'G'),
 (3,'Ich'),
 (4,'N'),
 (5,'X');
 
Testanweisung:
Löschen Sie aus t3, wo Name = „N“;

Der Debugging-Prozess ist in der Abbildung dargestellt:

Fazit: Beim Aktualisieren über einen gemeinsamen Index wird allen gemeinsamen Indizes, die die Bedingungen erfüllen, eine X-Sperre hinzugefügt, und den zugehörigen Primärschlüsselindizes wird eine X-Sperre hinzugefügt.

Der Ablauf ist wie folgt

Szenario 4: Löschen ohne Verwendung des Index

TABELLE ERSTELLEN `t4` (
 `id` int(11) NICHT NULL AUTO_INCREMENT,
 `name` varchar(10) NICHT NULL STANDARD '',
 PRIMÄRSCHLÜSSEL (`id`)
)

WERTE IN `t4` (`id`, `name`) EINFÜGEN 
 (1,'M'),
 (2,'J'),
 (3,'S'),
 (4,'Q'),
 (5,'L');
 
Löschen Sie aus t4, wo Name = "S";

Insgesamt gibt es 5 X-Schlösser, die restlichen 3 werden nicht einzeln aufgeführt.

Fazit: Beim Aktualisieren ohne Verwendung des Index durchsucht SQL die gesamte Tabelle mithilfe des gruppierten Index (Primärschlüsselindex), sodass jeder Datensatz gesperrt wird, unabhängig davon, ob er die Bedingungen erfüllt oder nicht. Es ist noch nicht vorbei…

Aus Effizienzgründen hat MySQL jedoch eine Optimierung vorgenommen. Für Datensätze, die die Bedingungen nicht erfüllen, werden die Sperren nach einer Beurteilung freigegeben. Die endgültigen Sperren sind diejenigen für Datensätze, die die Bedingungen erfüllen, aber die Sperr-/Freigabeaktionen für Datensätze, die die Bedingungen nicht erfüllen, werden nicht ausgelassen.

Der Ablauf ist wie folgt

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.