Mysql for update 导致大量行锁

一、引言

        最近同事的复盘会上提到自己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加锁的方式是从上到下的,自动加锁只有表级别的意向锁和行级锁,表级别的意向锁只会阻塞全表扫描

Mysql for update 导致大量行锁_第1张图片

 

5、RR级别加锁情况

        上文都是基于博主线上环境配置,如果是RR隔离级别,还会有GapLock与行锁进行Next_keyLock算法加锁,其实简单说就是锁住当前B+树种当前索引到上一个索引之间(或当前行到上一行)的间隔,防止在这个过程中有插入数据,也就是防止幻读。

Mysql for update 导致大量行锁_第2张图片

         但是这个情况不是绝对的,对于唯一索引,innodb会降低级别行级锁,不会锁住范围

三、总结

        通过以上分析得到结论:

1、RC级别下innodb都是行级锁,表级的意向锁只会阻塞全表扫描

2、innodb不存在锁升级

3、innodb加不到索引会搜索行,对主键加锁

4、当for update一个不存在的where条件时,Innodb加的是Record级别锁

以上分析除了实际操作验证和权威书籍理解之外,博主与DBA也经过深入探讨,如果有异议欢迎讨论。

另外希望各位同学,多实际操作、多看权威书籍和源码,对于网上的博客看一半信一半,要有自己的判断,书籍和源码的查看也要结合实际经验,因为每个人的脑回路是不一样的,一不小心理解方向就可能歪了。

你可能感兴趣的:(Mysql,mysql,数据库)