MySQL InnoDB锁先容及差异SQL语句别离加什么样的锁

上图中，在差异的断绝级别下，执行了沟通的SQL。无论何种断绝级别，PRIMARY上的index record lock老是会加的，我们不接头它。在idx_b上，断绝级别为RC时，InnoDB加了index record lock，即：X,REC_NOT_GAP，断绝级别为RR时，InnoDB加了next-key lock，即X。留意：RC时没有gap lock或next-key lock哦。

上图演示了：事宜的断绝级别也会影响到配置哪种锁。如我们前面所说，gap lock是用来阻止phantom row的，而RC时是应承phantom row，以是，RC时禁用了gap lock。因此，上图中，RC时没有在索引上配置gap lock或next-key lock。

实践四：操纵不存在的索引记录时，也必要加锁

上图中，idx_b上并不存在b=266的索引记录，那么，当更新b=266的记录时，是否必要加锁呢?是的，也必要加锁

无论b=266是否存在，RR时，InnoDB在第一个不满意搜刮前提的索引记录上配置gap lock或next-key lock。一样平常，等值前提时配置gap lock，范畴前提时配置next-key lock。上图中是等值前提，于是InnoDB配置gap lock，即上图的X,GAP，其范畴是(226, 2222)，正是此gap lock使得并发的事宜无法插入b列大于便是266的值，RC时，因为gap lock是被榨取的，因此，并不会加gap lock，并发的事宜可以插入b列大于便是266的值。

上图演示了：操纵不存在的索引记录时，也必要加锁。

实践五：一再键错误(duplicate-key error)时，会加共享锁。这也许会导致死锁。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!