In der Spalte „MySQL-Tutorial“ wird vorgestellt, wie Sperren das Phantomleseproblem lösen.

Vorwort

Heute werde ich Ihnen das Wissen rund um Sperren in MySQL vorstellen.

Verstehen Sie, was eine Sperre ist und wie Sie das Phantomleseproblem in MySQL lösen können Sofern nicht anders angegeben, verwendet dieser Artikel die Standard-InnoDB-Engine. Falls andere Engines oder Datenbanken beteiligt sind, wird darauf ausdrücklich hingewiesen.

Was ist eine Sperre? Mit einer Sperre kann sichergestellt werden, dass jede Transaktion weiterhin Daten auf konsistente Weise in einem gleichzeitigen Szenario lesen und ändern kann. Wenn eine Transaktion ein bestimmtes Datenelement sperrt, können andere Transaktionen nicht geändert werden kann nur blockieren und auf die Freigabe der Sperre warten, sodass die Granularität der Sperre die Leistung des Datenbankzugriffs bis zu einem gewissen Grad beeinträchtigen kann.

In Bezug auf die Sperrgranularität können wir Sperren in Tabellensperren und Zeilensperren unterteilen.

Tabellensperre

Wie der Name schon sagt, dient die Tabellensperre dazu, die Tabelle direkt zu sperren. In der MyISAM-Engine gibt es nur eine Tabellensperre.

Die Sperrmethode der Tabellensperre lautet:

LOCK TABLE 表名 READ;--锁定后表只读
UNLOCK TABLE; --解锁复制代码

Nach dem Login kopieren

Zeilensperre

Zeilensperre dient dem Namen nach dazu, eine Datenzeile zu sperren. Der tatsächliche Implementierungsalgorithmus der Zeilensperre ist jedoch relativ kompliziert, und manchmal ist er es auch nicht nur eine Sperre. Speichern Sie ein bestimmtes Datenelement und erweitern Sie es später.

Die normale Idee ist: Nach dem Sperren einer Datenzeile können andere Transaktionen nicht auf diese Daten zugreifen. Dann stellen wir uns vor, dass Transaktion A, wenn sie auf ein Datenelement zugreift, es einfach zum Lesen herausnimmt und es nicht ändern möchte Kommt es vor, dass ich bei Transaktion B auch auf diese Daten zugreifen möchte, sie nur herausnehmen und lesen möchte und sie nicht ändern möchte. Wenn sie zu diesem Zeitpunkt blockiert sind, wäre das eine kleine Verschwendung der Leistung. Um dieses Datenleseszenario zu optimieren, unterteilen wir Zeilensperren in zwei Haupttypen:

gemeinsame Sperren und exklusive Sperren

Gemeinsame Sperre

Gemeinsame Sperre, auch Lesesperre oder S-Sperre genannt, bedeutet, dass nach dem Hinzufügen eines Datenelements mit einer S-Sperre auch andere Transaktionen die Daten lesen und eine Sperre teilen können.

Wir können eine gemeinsame Sperre durch die folgende Anweisung hinzufügen:

select * from test where id=1 LOCK IN SHARE MODE;复制代码

Nach dem Login kopieren

Nach dem Sperren wird die Sperre aufgehoben, bis die gesperrte Transaktion endet (Commit oder Rollback). Exklusive Sperre

Exklusive Sperre, Exklusive Sperre, auch Schreibsperre, X-Sperre genannt. Das heißt, nachdem einem Datenelement eine X-Sperre hinzugefügt wurde, können andere Transaktionen, die auf diese Daten zugreifen möchten, nur blockieren und auf die Freigabe der Sperre warten, was exklusiv ist.

MySQL fügt automatisch eine exklusive Sperre hinzu, wenn wir die Daten ändern, z. B. Einfügen, Aktualisieren, Löschen. Ebenso können wir manuell eine exklusive Sperre über die folgende SQL-Anweisung hinzufügen:

select * from test where id=1 for update;复制代码

Nach dem Login kopieren

In der InnoDB-Engine handelt es sich um Zeilensperren und Tabellensperren dürfen gleichzeitig existieren.

Aber es wird ein Problem geben, wenn Transaktion A eine Datenzeile in Tabelle t sperrt und Transaktion B Tabelle t sperren möchte, was sollten wir zu diesem Zeitpunkt tun? Woher weiß Transaktion B, ob in Tabelle t eine Zeilensperre vorhanden ist und die Daten in der Tabelle groß sind, dauert das Sperren einen halben Tag, daher hat MySQL eine „Absichtssperre“ eingeführt.

Intention Lock

Intention Lock ist eine Tabellensperre, die in zwei Typen unterteilt ist: Intention Shared Lock und Intention Exclusive Lock. Diese beiden Sperren können als IS-Sperren bzw. IX-Sperren bezeichnet werden.

Absichtssperren werden von MySQL selbst verwaltet und Benutzer können Absichten nicht manuell hinzufügen.

Es gibt zwei wichtige Sperrregeln für Absichtssperren:

Wenn es erforderlich ist, einer Datenzeile eine S-Sperre hinzuzufügen, fügt MySQL zunächst eine IS-Sperre zur Tabelle hinzu.

Wenn es erforderlich ist, einer Datenzeile eine X-Sperre hinzuzufügen, fügt MySQL zunächst eine IX-Sperre zur Tabelle hinzu.

In diesem Fall lässt sich das obige Problem leicht lösen. Wenn Sie eine Tabelle sperren müssen, müssen Sie nur prüfen, ob die Tabelle über eine entsprechende Absichtssperre verfügt, ohne die gesamte Tabelle zu durchlaufen.

Kompatibilität verschiedener Schlösser

KonfliktSTeilen

锁到底锁的是什么

建立以下两张表，并初始化5条数据，注意test表有2个索引而test2没有索引：

CREATE TABLE `test` (
  `id` int(11) NOT NULL,
  `name` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `NAME_INDEX` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO test VALUE(1,'张1');
INSERT INTO test VALUE(5,'张5');
INSERT INTO test VALUE(8,'张8');
INSERT INTO test VALUE(10,'张10');
INSERT INTO test VALUE(20,'张20');

CREATE TABLE `test2` (
  `id` varchar(32) NOT NULL,
  `name` varchar(32) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO test2 VALUE(1,'张1');
INSERT INTO test2 VALUE(5,'张5');
INSERT INTO test2 VALUE(8,'张8');
INSERT INTO test2 VALUE(10,'张10');
INSERT INTO test2 VALUE(20,'张20');复制代码

Nach dem Login kopieren

举例猜测

在行锁中，假如我们对一行记录加锁，那么到底是把什么东西锁住了，我们来看下面两个例子：
举例1（操作test表）：

Teilen.			„sich gegenseitig ausschließend“ re
Teilen

事务A	事务B
BEGIN;
SELECT * FROM test WHERE id=1 FOR UPDATE;
	SELECT * FROM test WHERE id=1 FOR UPDATE; 阻塞
	SELECT * FROM test WHERE id=5 FOR UPDATE; 加锁成功
COMMIT; （释放锁）
	SELECT * FROM test WHERE id=1 FOR UPDATE; 加锁成功

举例2（操作test2表）：

事务A	事务B
BEGIN;
SELECT * FROM test2 WHERE id=1 FOR UPDATE;
	SELECT * FROM test2 WHERE id=1 FOR UPDATE; 阻塞
	SELECT * FROM test2 WHERE id=5 FOR UPDATE; 阻塞
COMMIT; （释放锁）
	SELECT * FROM test2 WHERE id=1 FOR UPDATE; 加锁成功

从上面两个例子我们可以发现，test表好像确实是锁住了id=1这一行的记录，而test2表好像不仅仅是锁住了id=1这一行记录，实际上经过尝试我们就知道，test2表是被锁表了，所以其实MySQL中InnoDB锁住的是索引，当没有索引的时候就会锁表。

接下来再看一个场景：

事务A	事务B
BEGIN;
SELECT * FROM test WHERE name=‘张1’ FOR UPDATE;
	SELECT name FROM test WHERE name=‘张1’ FOR UPDATE; 阻塞
	SELECT id FROM test WHERE id=1 FOR UPDATE; 阻塞
COMMIT; （释放锁）
	SELECT id FROM test WHERE id=1 FOR UPDATE; 加锁成功

这个例子中我们是把name索引锁住了，然后我们在事务B中通过主键索引只查id，这样就用到name索引了，但是最后发现也被阻塞了。所以我们又可以得出下面的结论，MySQL索引不但锁住了辅助索引，还会把辅助索引对应的主键索引一起锁住。

到这里，可能有人会有怀疑，那就是我把辅助索引锁住了，但是假如加锁的时候，只用到了覆盖索引，然后我再去查主键会怎么样呢？

接下来让我们再验证一下：

事务A	事务B
BEGIN;
SELECT name FROM test WHERE name=‘张1’ FOR UPDATE;
	SELECT name FROM test WHERE name=‘张1’ FOR UPDATE; 阻塞
	SELECT * FROM test WHERE id=1 FOR UPDATE; 阻塞
	SELECT id FROM test WHERE id=1 FOR UPDATE; 阻塞
COMMIT; （释放锁）
	SELECT id FROM test WHERE id=1 FOR UPDATE; 加锁成功

Wir können sehen, dass MySQL auch dann den Primärschlüsselindex sperrt, wenn nur die Hilfsindexsperre verwendet wird, und der B+-Baumblattknoten des Primärschlüsselindex die gesamten Daten speichert, sodass jedes abgefragte Feld gesperrt wird.

An diesem Punkt können wir eindeutig eine Schlussfolgerung darüber ziehen, was die Sperre ist:

Schlussfolgerung

In der InnoDB-Engine ist der Index gesperrt:

Wenn eine Tabelle keinen Index hat, wird MySQL gesperrt die Tabelle (Tatsächlich ist der Primärschlüsselindex der ausgeblendeten Spalte ROWID gesperrt)
Wenn wir den Hilfsindex sperren, wird auch der dem Hilfsindex entsprechende Primärschlüsselindex gesperrt
Der Primärschlüsselindex ist gesperrt, was eigentlich dem gesamten entspricht Alle Datensätze sind gesperrt (der Primärschlüssel-Indexblattknoten speichert die gesamten Daten)

Der Zeilensperralgorithmus

Als wir im vorherigen Artikel Transaktionen eingeführt haben, haben wir erwähnt, dass MySQL Phantom-Lesevorgänge verhindert durch Sperren, aber wenn die Zeilensperre nur eine Zeile von Datensätzen sperrt und das Phantomlesen nicht zu verhindern scheint, ist die Zeilensperre nur einer der Fälle. Tatsächlich gibt es drei Algorithmen für Zeilensperren: Datensatzsperre. Lückensperre und Next-Key-Sperre (Next-Key-Sperre), und der Grund, warum sie das Phantomlesen verhindern können, ist genau die Rolle der Next-Key-Sperre.

Datensatzsperre

Datensatzsperre wird oben eingeführt. Wenn unsere Abfrage einen Datensatz treffen kann, verwendet InnoDB die Datensatzsperre, um die Trefferzeile der Datensätze zu sperren.

Lückensperre

Wenn unsere Abfrage den Datensatz nicht erreicht, fügt InnoDB zu diesem Zeitpunkt eine Lückensperre hinzu.

Transaktion A	Transaktion B
BEGIN;
SELECT * FROM test WHERE id=1 FOR UPDATE;
	In den Test einfügen VALUE (2,'Zhang 2'); Blocking
	INSERT INTO test VALUE (3,'Zhang 3'); Blocking
	SELECT * FROM test WHERE id= 2 FÜR UPDATE; Erfolgreich sperren
COMMIT; (Sperre freigeben)

Aus dem obigen Beispiel können wir die Schlussfolgerung ziehen:

Gap Lock und Gap Lock Es gibt Es gibt keinen Konflikt zwischen ihnen, das heißt, Transaktion A fügt eine Lückensperre hinzu, und Transaktion B kann eine Lückensperre in derselben Lücke hinzufügen. (Der Grund, warum Lückensperren verwendet werden, liegt darin, dass keine Datentreffer vorliegen, sodass keine Notwendigkeit besteht, das Lesen zu blockieren, und dass keine Notwendigkeit besteht, andere Transaktionen daran zu hindern, dieselbe Lücke zu schließen.)
Lückensperren blockieren hauptsächlich Einfügungsvorgänge

Wie wird die Lücke bestimmt?

Die Testtabelle enthält 5 Datensätze und die Primärschlüsselwerte sind: 1,5,8,10,20. Dann gibt es die folgenden sechs Lücken:
(-∞,1),(1,5),(5,8),(8,10),(10,20),(20,+∞)

Und Wenn der Primärschlüssel nicht vom Typ int ist, wird er in ASCII-Code umgewandelt und anschließend die Lücke ermittelt.

Next-Key Lock

Next-Key Lock ist eine Kombination aus Record Lock und Gap Lock. Wenn wir eine Bereichsabfrage durchführen und nicht nur einen oder mehrere Datensätze treffen, sondern auch Lücken einschließen, wird die temporäre Schlüsselsperre als Standardalgorithmus für Zeilensperren in InnoDB verwendet.

Hinweis: Für die RC-Isolationsstufe werden zusätzlich zu Fremdschlüsseleinschränkungen und Eindeutigkeitsbeschränkungen natürlich keine Lückensperren hinzugefügt Die auf der RC-Ebene hinzugefügten Sperren sind alle Datensatzsperren. Wenn kein Datensatz getroffen wird, wird keine Sperre gesperrt. Daher löst die RC-Ebene das Problem des Phantomlesens nicht.

Die temporäre Tastensperre wird unter den folgenden zwei Bedingungen auf eine Lückensperre oder eine Datensatzsperre herabgestuft:

Wenn auf einen Datensatz mit dem Primärschlüssel oder einem eindeutigen Index zugegriffen wird, wird er auf eine Datensatzsperre herabgestuft.

Transaktion ATransaktion BBEGIN;SELECT * FROM test WHERE id>=2 AND idINSERT INTO test VALUE (2,'Zhang 2');INSERT INTO test VALUE (6,'Zhang 6') ); INSERT INTO test VALUE (8,'张8');SELECT * FROM test WHERE id=8 FOR UPDATE;INSERT INTO test VALUE (9,'Zhang 9');COMMIT;

上面这个例子，事务A加的锁跨越了(1,5)和(5,8)两个间隙，且同时命中了5，然后我们发现我们对id=8这条数据进行操作也阻塞了，但是9这条记录插入成功了。

临键锁加锁规则

临键锁的划分是按照左开右闭的区间来划分的，也就是我们可以把test表中的记录划分出如下区间：(-∞,1],(1,5],(5,8],(8,10],(10,20],(20,+∞)。

那么临键锁到底锁住了哪些范围呢？

**临键锁中锁住的是最后一个命中记录的 key 和其下一个左开右闭的区间**

那么上面的例子中其实锁住了(1,5]和(5,8]这两个区间。

临键锁为何能解决幻读问题

临键锁为什么要锁住命中记录的下一个左开右闭的区间？答案就是为了解决幻读。

我们想一想上面的查询范围id>=2且id

当然，其实如果我们执行的查询刚好是id>=2且id

在我们使用锁的时候，有一个问题是需要注意和避免的，我们知道，排它锁有互斥的特性。一个事务持有锁的时候，会阻止其他的事务获取锁，这个时候会造成阻塞等待，那么假如事务一直等待下去，就会一直占用CPU资源，所以，锁等待会有一个超时时间，在InnoDB引擎中，可以通过参数：innodb_lock_wait_timeout查询：

SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';复制代码

Nach dem Login kopieren

默认超时时间是50s，超时后会自动释放锁回滚事务。但是我们想一下，假如事务A在等待事务B释放锁，而事务B又在等待事务A释放锁，这时候就会产生一个等待环路了，而这种情况是无论等待多久都不可能会获取锁成功的，所以是没有必要去等50s的，这种形成等待环路的现象又叫做死锁。

死锁(Dead Lock)

什么是死锁

死锁是指的两个或者两个以上的事务在执行过程中，因为争夺锁资源而造成的一种互相等待的现象。





	blocking
	Blockieren
	blocking
	blocking
	Einfügung erfolgreich
(Sperre freigeben)

事务A	事务B
BEGIN;
SELECT * FROM test WHERE id=10 FOR UPDATE;
	BEGIN;
	SELECT * FROM test WHERE id=20 FOR UPDATE;
SELECT * FROM test WHERE id=20 FOR UPDATE;
	SELECT * FROM test WHERE id=10 FOR UPDATE;
	ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
查询出结果

Wir können sehen, dass ein Deadlock sofort zurückgesetzt wird, anstatt 50 Sekunden lang ziellos darauf zu warten, dass die Transaktion abläuft, bevor die Transaktion zurückgesetzt wird. Woher weiß MySQL, dass ein Deadlock aufgetreten ist, und wie macht es das? Den Deadlock erkennen? Was ist mit der Sperre passiert?

Deadlock-Erkennung

Derzeit verwenden die meisten Datenbanken die Wartediagramm-Methode (Wartediagramm), um Deadlocks zu erkennen. Die InnoDB-Engine verwendet diese Methode auch, um Deadlocks zu erkennen. In der Datenbank werden zwei Arten von Informationen aufgezeichnet:

Sperrinformationsliste
Transaktionswarteliste
Wartediagrammalgorithmus erstellt ein Diagramm basierend auf diesen beiden Informationen beweist, dass ein Deadlock vorliegt:
Wie in der folgenden Abbildung gezeigt, gibt es eine Schleife zwischen t1 und t2, die beweist, dass zwischen den Transaktionen von t1 und t2 ein Deadlock besteht

Deadlock vermeiden

Versuchen Sie es Teilen Sie lange Transaktionen in mehrere kleine Transaktionen auf
Vermeiden Sie beim Abfragen Abfragen ohne Where-Bedingungsanweisungen und verwenden Sie Indexabfragen so oft wie möglich.
Versuchen Sie nach Möglichkeit, gleichwertige Abfragen zu verwenden.

Abfrage von Sperrinformationen Die information_schema-Bibliothek dient uns zur Abfrage und Fehlerbehebung bei Fragen zu Transaktionen und Sperren.

INNODB_TRX

zeichnet Informationen zu jeder aktuell in InnoDB ausgeführten Transaktion auf, einschließlich der Frage, ob die Transaktion auf eine Sperre wartet, wann die Transaktion gestartet wurde und welche SQL-Anweisung (falls vorhanden) die Transaktion ausführt.

trx_started trx_requested_lock_idtrx_wait_started trx_weighttrx_mysql_thread_idtrx_querytrx_operation_statetrx_tables_in_usetrx_tables_lockedtrx_lock_structstrx_lock_memory_bytestrx_rows_locked trx_concurrency_ticketsDie Anzahl der Parallelität bezieht sich auf die Anzahl der Zeilen, die noch geändert oder eingefügt werden können, bevor die aktuelle Transaktion endet. Die Anzahl der gleichzeitigen Ausführungen kann über die Systemvariable innodb_concurrency_ticketstrx_isolation_levelThe festgelegt werden aktuelle Isolationsstufe der Transaktiontrx_unique_checksOb die eindeutige Einschränkung für die aktuelle Transaktion geöffnet oder geschlossen werden soll: 0-nein 1-jatrx_foreign_key_checks Ob Fremdschlüsseleinschränkungen für die aktuelle Transaktion aktiviert oder deaktiviert sind : 0-nein 1-jatrx_last_foreign_key_errorDie letzte Fremdschlüssel-Fehlermeldung, wenn nicht, ist sie leertrx_adaptive_hash_latchedob der adaptive Hash-Index durch die aktuelle Transaktion gesperrt ist. Wenn ein partitioniertes adaptives Hash-Index-Suchsystem verwendet wird, sperrt eine einzelne Transaktion nicht den gesamten adaptiven Hash-Index. Die adaptive Hash-Indexpartitionierung wird durch innodb_adaptive_hash_index_parts gesteuert, das standardmäßig auf 8 eingestellt ist. trx_adaptive_hash_timeout Ob der Suchlatch für den adaptiven Hash-Index sofort aufgegeben oder bei Aufrufen von MySQL beibehalten werden soll. Wenn kein adaptiver Hash-Indexkonflikt besteht, bleibt dieser Wert Null und Anweisungen halten Latches, bis sie abgeschlossen sind. Während des Konflikts wird die Anzahl auf Null reduziert und die Anweisung gibt den Latch unmittelbar nach jeder Zeilensuche frei. Dieser Wert bleibt 0, wenn das adaptive Hash-Index-Suchsystem partitioniert ist (gesteuert durch innodb_adaptive_hash_index_parts). trx_is_read_onlyOb die aktuelle Transaktion schreibgeschützt ist: 0-nein 1-jatrx_autocommit_non_lockingEin Wert von 1 bedeutet, dass es sich um eine Anweisung handelt, die keine Aktualisierung und Sperrung im Freigabemodell beinhaltet , und Autocommit ist aktiviert. In diesem Fall wird nur diese Anweisung ausgeführt. Wenn diese Spalte und TRX_IS_READ_ONLY beide 1 sind, optimiert InnoDB die Transaktion, um den Overhead zu reduzieren, der mit Transaktionen verbunden ist, die Tabellendaten ändern. INNODB_LOCKSSpaltennameBedeutunglock_idDie ID der Sperre (obwohl LOCK_ID derzeit TRX_ID enthält, kann sich das Datenformat in LOCK_ID jederzeit ändern. Schreiben Sie keine Anwendungen, die LOCK_ID-Werte analysieren )

Spaltenname	Bedeutung: RUNNING, LOCK WAIT, ROLLING ZURÜCK, COMMIT TING
Die Startzeit der Transaktion
Die Sperr-ID der wartenden Transaktion. Wenn trx_state nicht LOCK WAIT ist, ist sie null
Die Zeit, die die Transaktion auf den Start wartet
transactional Die Gewichtung spiegelt die Anzahl der von einer Transaktion geänderten und gesperrten Zeilen wider. Wenn ein Deadlock auftritt, wählt InnoDB die Transaktion mit dem kleinsten Wert zum Zurücksetzen aus.
Die Thread-ID in MySQL kann abgefragt werden über SHOW PROCESSLIST
SQL-Anweisungen, die von der Transaktion ausgeführt werden
Der aktuelle Betriebsstatus der Transaktion, wenn nicht NULL
Die Anzahl der von der verwendeten Tabellen In der aktuellen Transaktion ausgeführte SQL-Anweisungen
Die Anzahl der gesperrten Tabellen (da Zeilensperren verwendet werden). Obwohl eine Tabelle als gesperrt angezeigt wird, kann es sein, dass nur eine oder einige Zeilen gesperrt sind, sodass andere Zeilen gesperrt werden können auf die noch andere Transaktionen zugreifen können)
Die Anzahl der von der aktuellen Transaktion beibehaltenen Sperren
Die Größe der Indexstruktur der aktuellen Transaktion im Speicher
Die ungefähre Zahl Anzahl der Sperren in der aktuellen Transaktion. Anzahl der Zeilen, einschließlich derjenigen, die gelöscht wurden. Markieren Sie Löschmarkierungen und andere Daten, die physisch vorhanden sind, aber für die aktuelle Transaktion unsichtbar sind. Trx_rows_modified. Die Anzahl der Zeilen, die durch die aktuelle Transaktion geändert oder eingefügt wurden









zeichnet Informationen für jede Sperre auf, die eine Transaktion angefordert, aber nicht erhalten hat, und Informationen für jede Sperre, die eine Transaktion hielt, aber eine andere Transaktion blockierte.

lock_trx_id

Transaktions-ID der vorherigen Tabelle

lock_modeSperrmodus: S, Zeilensperrelock_tableDie gesperrte Tabellelock_ indexDer gesperrte Index, der Die Tabellensperre ist NULL. Die Tabellensperre ist NULL Die Anzahl der durch Transaktionen gesperrten Zeilen, die Tabellensperre ist NULLlock_dataDer Primärschlüsselwert der Transaktionssperre, die Tabellensperre ist NULL

INNODB_LOCK_WAITS

zeichnet Sperrwarteinformationen auf. Jede blockierte InnoDB-Transaktion enthält eine oder mehrere Zeilen, die die angeforderte Sperre und alle Sperren darstellen, die die Anforderung blockiert haben.

Spaltenname	Bedeutung
lock_id	Die ID der Sperre (obwohl LOCK_ID derzeit TRX_ID enthält, kann sich das Datenformat in LOCK_ID jederzeit ändern. Schreiben Sie keine Anwendungen, die LOCK_ID-Werte analysieren )
requesting_trx_id	Die Transaktions-ID der angeforderten Sperrressource
requested_lock_id	Die ID der angeforderten Sperre
blocking_trx_id	Die blockierte Transaktions-ID
blocking_lock _id	Die ID des blockierten Schlosses

Weitere verwandte kostenlose Lernempfehlungen: MySQL-Tutorial(Video)

Das obige ist der detaillierte Inhalt vonVerstehen Sie, was eine Sperre ist und wie Sie das Phantomleseproblem in MySQL lösen können. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!