大家好，我是狮子座。上一篇文章可能介绍了录制性能慢的原因。图案我们将介绍一些相关的幻觉知识，以及与间隙锁相关的间隙锁的解决方案。
两项交易的数据操作不会相互干预。事务A首先进行数据查询，交易B执行交易修改和数据提交，而交易A将进行另一个查询。数据没有更改。
这两项交易由两项交易进行操作，交易首先进行数据查询，交易B执行交易修改和数据提交，而交易A将进行另一次查询。数据是修改后的数据。
如下图所示，让我们一起分析。
如果相同的数据看到不同的结果，则将这种交易打开到交易的结尾。我们称为幻觉。
当前读取添加锁。当前的阅读规则是查看所有提交的数据。
如下图所示，让我们继续分析
会话B更新的第二个语句t集C = 5其中ID = 0，语义为“我更改了ID = 0的C值，d = 5至5”。
因为在T1时，会话A仅在ID = 5的行中添加一条锁，并且不会将锁添加到ID =0。因此，会话B可以在T2.in上执行这两个更新语句，会话A中的Q1语句是锁定所有d = 5行的锁定语句。
会话C的相同原因C。ID= 1行的修改也破坏了Q1锁定语句。
以上是语义问题。下面还有数据一致性
我们知道锁的设计是确保数据的一致性。这种一致性不仅是目前数据库的内部数据状态的一致性，而且还包含数据和日志的逻辑一致性。
如下图所示，我们将继续分析将是什么问题。
为了说明此问题，我在T1时为会话A添加了另一个更新语句，即：更新t集d = 100 d = 5。
更新与更新相同。它们用5锁定数据。
看来没有逻辑和一致性问题。请查看Binlog日志
您会发现这三行的结果已经变成（0,5,100），（1,5,100）和（5,5,100）。也就是说，已经更改了两个数据。
那么我们应该如何更改？如下所示，添加了锁
由于会话a在所有行中添加了一个锁，因此执行第一个更新语句时会话B锁定。必须等到T6时提交会话A，并且会话B可以继续执行。
通过这种方式，ID = 0的最终结果是数据库中的（0,5,5）。在binlog中，序列就是这样：
上图中的Binlog数据不一致的问题是解决的。该值也正确。然后还有另一个问题！
所有锁均求解每个数据的正确性，然后新数据无法确保正确性。现在，读写锁定并不能解决。
今天我们谈论了差距锁。介绍。例如，表中有6行数据。然后添加7个差距锁。这些7个锁在每个记录之前和之后分发。
当您执行select *从t = 5时进行选择时，更新时。不仅要在数据库中的现有6个记录中添加线路锁定，还可以同时添加7个差距锁。插入。
可以使用锁，数据行之间的差距以及可以与锁一起添加的实体添加数据行。
锁定锁分为：读取锁，写锁。
间隙锁定是一个单独的锁。
换句话说，与线路锁定存在冲突。
差距锁定是“在此差距中插入记录”的操作。间隙锁之间没有冲突。
以一个例子来解释
差距锁和线路锁称为Next-Key锁，每个下一键锁
然后，当我们用于更新时，我们添加了7个下一键锁，即（-∞，0]（0,5]，（5,10），（10,15]，（15,2020）（20，25]，（25， +turemum]。
超级：因为 +∞是开放范围。在实现条款中，InnoDB将每个索引的索引添加到最大值spremum，以便满足我们前面提到的“前后区域”。
引入GAP锁定和下一键锁帮助我们解决了幻想问题，但也带来了一些“麻烦”。
让我们首先引用逻辑以继续理论！
**业务逻辑**这是：任意锁定。如果不存在此行，请插入并在存在的情况下更新其数据
一旦这种逻辑同时发生，它将遇到僵局。您还必须觉得这很奇怪。每次此逻辑时，此逻辑都会锁定以进行更新。这已经是最严格的模式。怎么会有僵局？
如下所示，假设n = 9
在这一点上，两次会议已经进入了彼此等待形成死锁的状态。当然，InnoDB的僵局检测立即发现了致命的锁定关系，这使会插入会议的插入声明是报告的错误。
结论：缝隙锁的引入可能导致相同的语句锁定更大的范围，这实际上会影响并发
从一开始，我们提到幻想阅读只会在重复隔离级别的情况下出现。差距锁定会在重复阅读的水平下生效。
因此，如果设置隔离级别以读取和提交，则没有差距锁定。Row.这也是许多公司现在使用的配置组合。
由间隙锁引起的死锁通常会在生产数据库上发生。线路锁确实更直观，判断规则相对简单。缝隙锁的引入将影响系统的并发性并增加锁分析的复杂性，但也有一些章节可供章节。