MySQL 通过在非索引列上执行删除语句时锁定整个表来尝试防止什么现象

使用可重复读的 MySQL 隔离级别。

给定表test具有非索引列quantity:

id    |     quantity
--------------------
1     |      10
2     |      20
3     |      30

Tx1执行第一个，注意它还没有提交，这意味着所有获取的锁还没有释放。

Tx1:

START TRANSACTION;
DELETE FROM test WHERE quantity=10;

现在执行Tx2

Tx2:

START TRANSACTION;
INSERT INTO test(quantity) VALUES (40);
COMMIT;

对于 Tx2，我得到以下结果：

Lock wait timeout exceeded; try restarting transaction

我理解，作为quantity列没有索引，delete语句进行全表扫描，锁定所有行（无关紧要where条件匹配或不匹配），并且还在聚集索引中的每个索引记录之前和之后应用间隙锁，从而导致表完全阻塞insert来自 tx2 的语句无法获取要插入的行的锁。

来自 MySQLmanual https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html（对于可重复读隔离级别）：

• 对于具有唯一搜索条件的唯一索引，InnoDB 仅锁定找到的索引记录，而不锁定其之前的间隙。

• 对于其他搜索条件，InnoDB 会锁定扫描的索引范围，使用间隙锁或下一个键锁来阻止其他会话插入该范围所覆盖的间隙（这在我的例子中使用）。

考虑到任何给定隔离级别中的锁定都用于防止phenomenas我有点困惑在这种情况下阻止整个表的原因是什么，我的意思是什么样的phenomena在这种情况下可以阻止整个表的阻塞吗？

默认情况下，InnoDB 使用一致快照Repeatable Read https://vladmihalcea.com/non-repeatable-read/隔离级别，这意味着您可以获得元组和范围的可重复读取。

即使 SQL 标准这么说Phantom Reads https://vladmihalcea.com/phantom-read/被阻止Serializable然后Repeatable Read可能无法阻止它。

有关间隙锁定如何工作的更多详细信息，请查看这篇文章由 Percona 撰写 https://www.percona.com/blog/2012/08/28/differences-between-read-committed-and-repeatable-read-transaction-isolation-levels/.