Eine kurze Analyse der Transaktionsisolationsstufe in MySQL und eine Diskussion seiner Implementierungsprinzipien

Es ist ersichtlich, dass, wenn nur Sperren zur Implementierung der Isolationsstufensteuerung verwendet werden, häufiges Sperren und Entsperren erforderlich ist und leicht Lese- und Schreibkonflikte auftreten können (z. B. aktualisiert Transaktion A auf RC-Ebene Datenzeile 1 und Transaktion B Bevor dann Transaktion A festgeschrieben wird, muss die Lesedatenzeile 1 darauf warten, dass Transaktion A festgeschrieben und die Sperre aufgehoben wird.

Um das Problem von Lese- und Schreibkonflikten ohne Sperren zu lösen, hat MySQL den MVCC-Mechanismus eingeführt. Weitere Informationen finden Sie in meinem vorherigen Analyseartikel: Optimistische Sperren, pessimistische Sperren und MVCC in der Datenbank in einem Artikel verstehen.

Implementierungsprinzip der InnoDB-Transaktionsisolationsebene

Bevor wir mit der Analyse fortfahren, müssen wir zunächst einige Konzepte verstehen:

1 Transaktion, sperren Sie das Lesen aktiv, z. B. SELECT ... LOCK IN SHARE MODE und SELECT ... FOR UPDATE. Es werden jeweils gemeinsame Zeilensperren und exklusive Zeilensperren hinzugefügt. Die Klassifizierung von Sperren finden Sie in meinem vorherigen Analyseartikel: MySQL-Sperrklassifizierungen, die Sie kennen sollten.

Konsistente nicht sperrende Lesevorgänge

https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html

2. Aktueller Read und Snapshot Read

Der aktuelle Read

UPDATE, DELETE, INSERT, SELECT... LOCK IN SHARE MODE, SELECT... FOR UPDATEDiese Vorgänge sind alle aktuelle Lesevorgänge. Warum werden sie aktuelle Lesevorgänge genannt? Das heißt, es liest die neueste Version des Datensatzes. Beim Lesen muss auch sichergestellt werden, dass andere gleichzeitige Transaktionen den aktuellen Datensatz nicht ändern können und der gelesene Datensatz gesperrt wird.

Snapshot-Lesen

SELECT-Vorgang ist ein Snapshot-Lesen, also ein nicht blockierendes Lesen ohne Sperren. Die Voraussetzung für das Snapshot-Lesen ist die Isolationsstufe Es handelt sich nicht um die Ebenen „Uncommitted Read“ und „Serialized Read“, da beim Uncommitted Read immer die neueste Datenzeile gelesen wird und nicht die Datenzeile, die der aktuellen Transaktionsversion entspricht, und das Serialized Read die Tabelle sperrt

Die Sperre wird nur aufgehoben, wenn ein Commit oder Rollback ausgeführt wird, und alle Sperren werden gleichzeitig aufgehoben.

InnoDB unterstützt auch explizites Sperren (Storage-Engine-Schicht) durch spezifische Anweisungen

select ... lock in share mode //共享锁
select ... for update //排他锁

Explizites Sperren der MySQL-Server-Schicht:

lock table
unlock table

Nachdem wir die oben genannten Konzepte verstanden haben, nehmen wir eine Schauen Sie sich an, wie InnoDB-Transaktionen implementiert werden (die folgenden Lesungen beziehen sich alle auf nicht aktiv gesperrte Auswahlen)

• 事务隔离级别	实现方式
  未提交读（RU）	事务对当前被读取的数据不加锁，都是当前读； 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加行级共享锁，直到事务结束才释放。
  提交读（RC）	事务对当前被读取的数据不加锁，且是快照读； 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加行级排他锁（Record），直到事务结束才释放。
  可重复读（RR）	事务对当前被读取的数据不加锁，且是快照读； 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加行级排他锁（Record，GAP，Next-Key），直到事务结束才释放。 通过间隙锁，在这个级别MySQL就解决了幻读的问题 通过快照，在这个级别MySQL就解决了不可重复读的问题
  序列化读（S）	事务在读取数据时，必须先对其加表级共享锁 ，直到事务结束才释放，都是当前读； 事务在更新数据时，必须先对其加表级排他锁 ，直到事务结束才释放。

  可以看到，InnoDB通过MVCC很好的解决了读写冲突的问题，而且提前一个级别就解决了标准级别下会出现的幻读问题，大大提升了数据库的并发能力。

  一些常见误区

  幻读到底包不包括了delete的情况?

  不可重复读：前后多次读取一行，数据内容不一致，针对其他事务的update和delete操作。为了解决这个问题，使用行共享锁，锁定到事务结束（也就是RR级别，当然MySQL使用MVCC在RC级别就解决了这个问题）

  幻读：当同一个查询在不同时间生成不同的行集合时就是出现了幻读，针对的是其他事务的insert操作，为了解决这个问题，锁定整个表到事务结束（也就是S级别，当然MySQL使用间隙锁在RR级别就解决了这个问题）

  网上很多文章提到幻读和提交读的时候，有的说幻读包括了delete的情况，有的说delete应该属于提交读的问题，那到底真相如何呢？我们实际来看下MySQL的官方文档（如下）

  The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT) is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.

  https://dev.mysql.com/doc/refman/5.7/en/innodb-next-key-locking.html

  可以看到，幻读针对的是结果集前后发生变化，所以看起来delete的情况应该归为幻读，但是我们实际分析下上面列出的标准SQL在RR级别的实现原理就知道，标准SQL的RR级别是会对查到的数据行加行共享锁，所以这时候其他事务想删除这些数据行其实是做不到的，所以在RR下，不会出现因delete而出现幻读现象，也就是幻读不包含delete的情况。

  MVCC能解决了幻读问题?

  网上很多文章会说MVCC或者MVCC+间隙锁解决了幻读问题，实际上MVCC并不能解决幻读问题。如以下的例子：

  begin;
  
  #假设users表为空，下面查出来的数据为空
  
  select * from users; #没有加锁
  
  #此时另一个事务提交了，且插入了一条id=1的数据
  
  select * from users; #读快照，查出来的数据为空
  
  update users set name='mysql' where id=1;#update是当前读，所以更新成功，并生成一个更新的快照
  
  select * from users; #读快照，查出来id为1的一条记录，因为MVCC可以查到当前事务生成的快照
  
  commit;

  Nach dem Login kopieren

  可以看到前后查出来的数据行不一致，发生了幻读。所以说只有MVCC是不能解决幻读问题的，解决幻读问题靠的是间隙锁。如下：

  begin;
  
  #假设users表为空，下面查出来的数据为空
  
  select * from users lock in share mode; #加上共享锁
  
  #此时另一个事务B想提交且插入了一条id=1的数据，由于有间隙锁，所以要等待
  
  select * from users; #读快照，查出来的数据为空
  
  update users set name='mysql' where id=1;#update是当前读，由于不存在数据，不进行更新
  
  select * from users; #读快照，查出来的数据为空
  
  commit;
  
  #事务B提交成功并插入数据

  Nach dem Login kopieren

  注意，RR级别下想解决幻读问题，需要我们显式加锁，不然查询的时候还是不会加锁的。

  原文地址：https://segmentfault.com/a/1190000025156465

  作者: X先生

  【相关推荐：mysql视频教程】