特别强调～

本测试使用的是MySQL 8.0.27～ 8.0.27～ 8.0.27（因为不同版本命令可能会有差异哈）

打开两个终端，分别连接上MySQL，使用select @@global.transaction_isolation;查看隔离级别（间隙锁要在可重复读的隔离级别下）

​如果报类似ERROR 1193 (HY000): Unknown system variable 'tx_isolation'的错，一般是版本问题

# 老版本：select @@global.tx_isolation;

select @@global.tx_isolation;

# 5.8版本之后使用：select @@global.transaction_isolation;

select @@global.transaction_isolation;

我们的测试表中的数据长这样

​事务1

终端A开启事务，查询id=5的数据（注意加上for update使用当前读）

select * from app_user_copy1 where id = 5 for update;

查看当前事务的锁信息

select * from performance_schema.data_locks;

• 在MySQL 5.5以上、5.7.14以下的版本中，用户可以通过INFORMATION_SCHEMA下的INNODB_TRX、INNODB_LOCKS以及INNODB_LOCK_WAITS这三张表简单地监控并分析可能存在的锁问题

• 在MySQL 8.0版本中，则需要使用performance_schema下的data_locks以及data_lock_waits获取相关的锁以及锁等待信息

• 而MySQL版本在5.7.14到8.0之间的用户，只能通过其它手段间接的获取上述信息

我们从LOCK_MODE列中可以看到此事当前事务有两把锁（后面附有各个列的含义介绍）

• 第一行LOCK_MODE为IX，即意向排他锁，属于表级锁

• 第二行LOCK_MODE为X,REC_NOT_GAP，表示当前仅为行记录锁，且非间隙锁，属于行级锁

打开一个终端B，同样开启事务，更新id=5的行数据，会进入阻塞

update app_user_copy1 set name='test' where id=5;

​等到超时了就报错

​分别插入 id=3 和 id=7 的数据

INSERT INTO `app_user_copy1` (`id`, `name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES (3, '用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 98, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

​INSERT INTO `app_user_copy1` (`id`, `name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES (7, '用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 98, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

​都插入成功，说明当命中🎯注解索引时，临键锁退化为行级锁，是不会加间隙锁的

事务1结束，将数据恢复至测试开始前

事务2

终端A开启事务，查询id=3的数据（注意加上for update使用当前读）

select * from app_user_copy1 where id = 3 for update;

查看当前事务的锁信息

select * from performance_schema.data_locks;

​可以看到，此时LOCK_MODE为X,GAP，LOCK_DATA为5，即加了间隙锁，锁住 id=5 的行数据前的间隙；

终端B开启事务，更新 id=1 跟 id=5 两个边界信息

update app_user_copy1 set name='test' where id = 1; update app_user_copy1 set name='test' where id = 5;

​都更新成功，即当命中间隙时，会锁住当前间隙，并且不包括前后两条数据（即开区间）

事务2结束，将数据恢复至测试开始前

事务3

终端A开启事务，查询 id > 3 and id <=5 的数据（注意加上for update使用当前读）

select * from app_user_copy1 where id > 3 and id <= 5 for update;

​查看当前事务的锁信息

select * from performance_schema.data_locks;

可以看到，此时LOCK_MODE为X，LOCK_DATA为5，即加了临键锁，锁住 id=5 的行数据以及其前的间隙；

终端B开启事务，更新 id=1 、id=5 的信息

update app_user_copy1 set name='test' where id = 1; update app_user_copy1 set name='test' where id = 5;

id=1 更新成功

​id=5 更新失败

​插入id=2数据，插入失败

INSERT INTO `app_user_copy1` (`id`, `name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES (2, '用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 98, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

插入id=7数据，插入成功

INSERT INTO `app_user_copy1` (`id`, `name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES (7, '用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 98, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

即临键锁会锁住当前记录以及记录前的间隙（左开右闭区间）

事务3结束，将数据恢复至测试开始前

事务4

终端A开启事务，查询 id > 3 and id < 9 的数据（注意加上for update使用当前读）

select * from app_user_copy1 where id > 3 and id < 9 for update;

​查看当前事务的锁信息

 select * from performance_schema.data_locks;

可以看到，此时有两个行级锁

• 第一个LOCK_MODE为X，LOCK_DATA为5，即加了临键锁，锁住 id=5 的行数据以及其前的间隙；

• 第二个LOCK_MODE为X,GAP，LOCK_DATA为9，即加了间隙锁，锁住 id=9 的行数据前的间隙；

终端B开启事务，更新 id=1 、id=5 、id=9 的信息

update app_user_copy1 set name='test' where id = 1; update app_user_copy1 set name='test' where id = 5; update app_user_copy1 set name='test' where id = 9; 

id=1 更新成功

id=5 更新失败

​id=9 更新成功

​插入id=2数据，插入失败

INSERT INTO `app_user_copy1` (`id`, `name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES (2, '用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 98, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

​插入id=7数据，插入失败

INSERT INTO `app_user_copy1` (`id`, `name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES (7, '用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 98, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

​即当查询的是一段范围时，会锁住在符合查询条件的所有数据行，以及范围内的所有间隙（开区间，除非该数据行符合查询条件） 事务5 前面4个测试我们都是使用的唯一的主键索引，下面我们用普通索引试下(￣∇￣)/ 终端A开启事务，查询 age=35 的数据（注意加上for update使用当前读）

select * from app_user_copy1 where age = 35 for update;

​查看当前事务的锁信息

 select * from performance_schema.data_locks;

可以看到，此时有3把行锁

• 第一行LOCK_MODE列中为X，即加了临键锁

  • LOCK_DATA为35, 5指的是 age=35 的 id=5 的数据

  • 锁住的范围是 age=35 的行数据以及其前间隙

• 第二行LOCK_MODE列中为X,REC_NOT_GAP

  • LOCK_DATA为5，即给 id=5 的行记录加了记录锁

• 第三行LOCK_MODE列中为X,GAP，即加了间隙锁

  • LOCK_DATA为37, 24的指的是 age=37 的 id=24 的数据

  • 锁住的范围是 age=37 的行数据前的间隙

我们把数据库数据按照age升序排列，如下图

终端B开启事务，做如下更新操作

update app_user_copy1 set name='test' where age = 33; update app_user_copy1 set name='test' where age = 35; update app_user_copy1 set name='test' where age = 37;

age=33 更新成功

​age=35 更新失败

age=37 更新成功

插入 age=34 数据，插入失败

INSERT INTO `app_user_copy1` (`name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES ('用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 34, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

​插入 age=36 数据，插入失败

INSERT INTO `app_user_copy1` (`name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES ('用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 36, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

​插入 age=38 数据，插入成功

INSERT INTO `app_user_copy1` (`name`, `email`, `phone`, `gender`, `password`, `age`, `create_time`, `update_time`) VALUES ('用户0', '123456@qq.com', '18582305042', 1, 'ef0641a4-7a7a-11ec-970f-7a9ea76b236f', 38, '2022-01-21 13:28:15', '2022-01-21 13:28:15');

​上面测试中WHERE后的条件都是加了索引的，如果该字段未加索引，则会锁表（未命中不锁）

总结

• LOCK_MODE列中为X，即加了临键锁，锁住的范围是LOCK_DATA中的行数据以及其前间隙（左开右闭）

• LOCK_MODE列中为X,REC_NOT_GAP，锁住的是LOCK_DATA中的行数据

• LOCK_MODE列中为X,GAP，锁住的是LOCK_DATA中的行数据前面的间隙（左开右开）