Mysql for update导致大量行锁的问题
作者：tingmailang
一、引言
最近同事的复盘会上提到自己for update一个不存在的where条件导致表锁，然后产生大量的事务失败和读写超时，这时博主非常奇怪，因为虽然网上许多博客写Innodb的表锁行锁与锁升级，但是事实上这都是错误的观点。
二、分析
首先博主的环境是Mysql5.7，隔离级别是RC
博主为什么说这些都是错误的观点呢？
因为在《高性能Mysql》和《Innodb存储引擎当中》，非常明确的提出：
1、Innodb不存在锁升级
所以不存在因为锁的数据量大或者多表，导致行锁升级成表锁。
2、当for update一个不存在的where条件时
Innodb加的是Record级别锁
这一点可以通过验证得到
- 不存在的where：
set autocommit = 0 ;
begin;
select * from t_aac_battery_compensate where gmt_create in ('2020-05-21 07:02:37') for update ;- 存在的where：
begin;
select * from t_aac_*** where gmt_create in ('2020-05-21 07:32:37') for update ;然后执行
select * from information_schema.INNODB_LOCKS il
可以看到锁
可以看到两个事务加的都是行级别锁。
可能有的同学会对锁住的行数量和数据有疑惑，这里博主发现这两个数值统计的方式是不准的，包括在《Innodb存储引擎》作者明确提出lock_data是不准确的。
也有的同学疑惑他加行锁为什么会阻塞其他读写，这里是innodb加了行锁之后最后一起释放，虽然不知道它这样的设计是出于什么考虑。
3、Innodb如果在索引中找不到记录
会在行数据进行搜索，锁住主键，而不是锁表
所以一些博客说根据索引加不到锁，innodb就会锁全表，这是错误的理解
只是可能在一些情况下他搜索行数据对主键加锁的数量过多，之前也说了innodb加行锁是最后一起释放的，所以阻塞了其他读写
4、Innodb加锁的方式是从上到下的
自动加锁只有表级别的意向锁和行级锁，表级别的意向锁只会阻塞全表扫描
5、RR级别加锁情况
上文都是基于博主线上环境配置，如果是RR隔离级别，还会有GapLock与行锁进行Next_keyLock算法加锁，其实简单说就是锁住当前B+树种当前索引到上一个索引之间（或当前行到上一行）的间隔，防止在这个过程中有插入数据，也就是防止幻读。
但是这个情况不是绝对的，对于唯一索引，innodb会降低级别行级锁，不会锁住范围
三、总结
通过以上分析得到结论：
1、RC级别下innodb都是行级锁，表级的意向锁只会阻塞全表扫描
2、innodb不存在锁升级
3、innodb加不到索引会搜索行，对主键加锁
4、当for update一个不存在的where条件时，Innodb加的是Record级别锁
以上分析除了实际操作验证和权威书籍理解之外，博主与DBA也经过深入探讨，如果有异议欢迎讨论。 另外希望各位同学，多实际操作、多看权威书籍和源码，对于网上的博客看一半信一半，要有自己的判断，书籍和源码的查看也要结合实际经验，因为每个人的脑回路是不一样的，一不小心理解方向就可能歪了。
好了，这些仅为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。