一、引言
最近同事的复盘会上提到自己for update一个不存在的where条件导致表锁,然后产生大量的事务失败和读写超时,这时博主非常奇怪,因为虽然网上许多博客写Innodb的表锁行锁与锁升级,但是事实上这都是错误的观点。
二、分析
首先博主的环境是Mysql5.7,隔离级别是RC
博主为什么说这些都是错误的观点呢?因为在《高性能Mysql》和《Innodb存储引擎当中》,非常明确的提出:
1、Innodb不存在锁升级,所以不存在因为锁的数据量大或者多表,导致行锁升级成表锁。
2、当for update一个不存在的where条件时,Innodb加的是Record级别锁
这一点可以通过验证得到
不存在的where | set autocommit = 0 ;
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级别锁