12｜数据库锁：明明有行锁，怎么突然就加了表锁？

研究过一段时间锁的机制。举几个点，来分享一下如何理解临键锁。 首先这个名词“临键”非常拗口难记，但是大家仔细观察它的英文“next-key lock”，就可以发现一些名堂，我个人认为，所谓next-key的意思就是下一个索引的意思，也就是锁住查询结果中的最大索引值与下一个索引值之间的区域。这就意味着，临键锁锁住的最后的那个区间，是当前命中的索引最大值到下一个索引的区间，如果没有下一个索引，那就是锁住了剩下所有区间。结合本文的例子，大家就容易理解了。 例子1：如果 id 只有（1，4，7）三条记录，你查的是where id = 3，虽然没有查到记录，但是由于innodb中RR级别会使用临键锁，于是临键锁要开始锁区间了，但是锁哪里呢？这时候就要理解“临键”了，就是“next-key”，那么"next-key"是谁呢，根据查询条件ID=3，那么3后面的下一个索引是几呢？是4！！ 那么临键锁就将（1，4]锁住了。 另外要额外提一句，由于查询条件可能是区间查询，所以临键锁会锁住多个区间。 比如查询条件 id>1 and id <6 它就会把(1, 4],(4,7]这两个区间都锁住。 又比如查询条件是id >1 and id<9 它就会把(1, 4],(4,7],(7, +∞]这三个区间都锁住，换句话说，这种查询也就导致了你根本插入不了任何一条记录，因为它把 id从1到无穷的范围都给锁住了。 为什么要锁住区间？因为要防止幻读出现（幻读就是同一事务里面，同一个sql查询查出来的记录行数不一样。为什么会不一样？因为有别的事务在你执行sql的时候进行了插入，插入到了你的查询条件范围内了，导致你上一次查还好好的，下一次查就莫名奇妙多出来记录了。）。 所以，你想，临键锁把你查询条件范围的区间锁住了，其它事务想往区间里面插数据是不是就不行了？临键锁是根据你的查询条件来锁区间的，这样你在同一事务里反复执行同一条sql查询，是不是就不会出现幻读了。 以上是个人浅见，欢迎指正。

《乐观锁与悲观锁》部分是不是有个BUG？ “悲观锁是指在写入数据时直接加锁”，我觉得应该是“悲观锁是指在获取数据时直接加锁”

意向锁除了变更表结构的例子，还是有其他的例子吗？毕竟意向锁有这么多的好处：使用意向锁能够提高数据库的并发性能，并且避免死锁问题。 SQL语句中怎么手动使用意向锁？

举个例子，如果数据库中只有 id 为（1，4，7）的三条记录，也就是 id= 3 这个条件没有命中任何数据，那么这条语句会加上间隙锁，而且是在 (-∞,1)、(1,4)、(7，+∞) 这些地方都加上间隙锁。所以你可以看到，在生产环境里面遇到了未命中索引的情况，对性能影响极大。 这个查询只会扫描到记录1和4吧，为什么7以后也加了间隙锁呢

之前写代码，事物里面，select语句从来不在后面加for update结尾。这样会有什么问题吗？

默默翻出尘封已久的高性能MYSQL...

老师 是怎么记忆这些锁知识的

当线程 1 想要执行插入的时候，它想要获得 id = 79 的行锁。当线程 2 想要执行插入的时候，它想要获得 id = 80 的行锁，这个时候就会出现死锁。因为线程 1 和线程 2 同时还在等着对方释放掉持有的间隙锁。 这里的图中，临时键 ==> 临键锁。

“临键锁和数据库隔离级别的联系最为紧密，它可以解决在可重复读隔离级别之下的幻读问题。” 解决幻读问题，应该是间隙锁吧。

记录锁，是不是就是行锁呀？如果是的话，为什么这里需要使用两个概念？如果不是的话，记录锁与行锁的区别是什么呢？