「本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！」
你好，我是yes。
前段时间写了一篇关于 MySQL 锁的文章，一些小伙伴们在阅读之后产生了一些疑问，这些问题还挺有代表性的，所以在这里做个实验，来用事实探究一番。
那篇文章提到了记录锁（Record Locks），顾名思义锁的是记录，作用在索引上的记录。
锁是作用在索引上这句话可能不太好理解，并且对于在可重复读和读提交两个隔离级别下，关于是否命中二级索引的锁之间的阻塞也不太清晰。
这句话读着可能有点拗口，没事，我来给你看几个实验，并且文末作了个概念性总结，看完之后想必对这一切就异常清晰了。
实验的 MySQL 版本为：5.7.26。
实验一：隔离级别为读提交，锁定非索引列的实验
先建个非常简单的表，只有主键索引，没有二级索引。
CREATE TABLE `yes` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(45) DEFAULT NULL, `address` varchar(45) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4
隔离级别如下：
锁的类型就是行级锁，此时的锁为 X 锁，锁的索引就是主键索引，这个结果表明的意思是事务 B（6517）想要 id 为 1 的记录锁，但是这个记录此时被事务A（6516）占有。
是的，这里的 1 其实不是指第一个记录的意思，是 id 为 1 的记录。
可能有人疑惑， 为啥 lock_data 为 1 ？
（我没看过源码，个人推断如下：）执行 select ... for update ，由于 name 字段没有索引，索引事务 A、B 只能加锁到主键索引上，此时需要搜索 name 为 yes 的记录，但是又没有索引，只能全表扫描，恰巧扫描第一条记录就符合要求了，于是上锁，然后接着往后扫描，后面不符合条件所以没有上锁。此时事务 B 加锁，过程和事务 A 一样需要从第一条记录开始扫描上锁，但此时第一条记录已经被事务 A 锁了，所以第一条记录就冲突了，而第一条记录的 id 就是为 1，因此 lock_data 为 1。
现在，我把事务 A 提交，则事务 B 里面能立马得到结果。
从上面这个实验可以得知，如果查询条件上锁，但是没有对应的二级索引可以命中，那么锁就会锁到主键(聚簇)索引上。
而聚簇索引的非叶子节点只有主键的信息，没有 name 的信息，所以只能按顺序的全表扫描，加锁符合条件的记录，但是在扫描过程中遇到已经被加锁的记录就会被阻塞，即使这个记录不是目标记录。
看下面这个实验，你就清晰了。
这个实验其实就是把事务 A、B的语句执行的顺序换了一下。
此时，新起一个事务 C，先执行如下语句，锁的是id为2的记录：
lock_data 变为 id 为 2 的记录了，也就是说事务 C 扫描了 id 为 1 的记录之后，发现不符合条件，就释放了，（不然 lock_data 的值应该为 1）然后继续扫描 id 为 2 的记录，符合条件，于是上锁。
而事务 D 也扫描了 id 为 1 的记录，符合条件，于是上锁，然后接着向后扫描到 id 为 2 的记录，但是此时已经被事务C 加锁了，于是被阻塞。
这结果也符合了我上面的推断。
我们再继续实验。
这次来试试 update 的，此时新起事务 E ：
并没有发生阻塞，这其实是符合我们预期的。但从中我们可以得知，在读提交级别下，即使没有索引，update 的全表扫描并不是和select ... for update那样全表按顺先加锁再判断条件，而是先找到符合的记录，然后再上锁。
我们再继续实验。
此时，把上面的事务都提交之后，再新起一个事务 G 执行以下语句，且不提交事务：
可以看到，冲突的还是 id 为 1 的这条记录，那说明事务 C 在全表扫描，从第一条开始遍历，即使访问到了不符合条件的记录，加锁之后在事务提交之前就不会释放！
这里就和读已提交有差别了。
我们再继续实验，此时提交事务A、B、C、D之后，再新起一个事务 E：
起冲突的 lock_data 是最大记录(supremum)，这个记录之前的文章提过的，MySQL页默认有最大和最小两条记录，不存储数据，作用类似于链表的 dummy 节点。
从这个结果来看，这个最大记录也被事务 F 锁了，这个表的 ID 是自增的，所以此时的插入记录，刚好要插入到最后面，这样就发生了冲突。
这其实有点出乎我的意料，我以为事务 F 插入应该是被事务 E 加的间隙锁给挡了才对。
这时候，我又做了个实验，我先造了一条 id 为 6 的记录，此时表内的数据如下：
看到截图的 X,GAP 没，结果显示插入的事务需要记录锁+间隙锁，但是被前一个事务占用的 id 为 6 的记录锁给阻塞了。
这涉及到我的盲区了，上面的插入还只要记录锁，这时候的插入就又要申请间隙锁了？但是也不是因为间隙被阻塞啊？我之后再找个时间研究下，如果有大佬知道，请评论区指导我下。
