一、引言

最近同事的復(fù)盤會上提到自己for update一個不存在的where條件導(dǎo)致表鎖，然后產(chǎn)生大量的事務(wù)失敗和讀寫超時，這時博主非常奇怪，因為雖然網(wǎng)上許多博客寫Innodb的表鎖行鎖與鎖升級，但是事實(shí)上這都是錯誤的觀點(diǎn)。

二、分析

首先博主的環(huán)境是Mysql5.7，隔離級別是RC

博主為什么說這些都是錯誤的觀點(diǎn)呢？

因為在《高性能Mysql》和《Innodb存儲引擎當(dāng)中》，非常明確的提出：

1、Innodb不存在鎖升級

所以不存在因為鎖的數(shù)據(jù)量大或者多表，導(dǎo)致行鎖升級成表鎖。

2、當(dāng)for update一個不存在的where條件時

Innodb加的是Record級別鎖

這一點(diǎn)可以通過驗證得到

• 不存在的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 ;

然后執(zhí)行

select * from information_schema.INNODB_LOCKS il?

可以看到鎖

可以看到兩個事務(wù)加的都是行級別鎖。

可能有的同學(xué)會對鎖住的行數(shù)量和數(shù)據(jù)有疑惑，這里博主發(fā)現(xiàn)這兩個數(shù)值統(tǒng)計的方式是不準(zhǔn)的，包括在《Innodb存儲引擎》作者明確提出lock_data是不準(zhǔn)確的。

也有的同學(xué)疑惑他加行鎖為什么會阻塞其他讀寫，這里是innodb加了行鎖之后最后一起釋放，雖然不知道它這樣的設(shè)計是出于什么考慮。

3、Innodb如果在索引中找不到記錄

會在行數(shù)據(jù)進(jìn)行搜索，鎖住主鍵，而不是鎖表

所以一些博客說根據(jù)索引加不到鎖，innodb就會鎖全表，這是錯誤的理解

只是可能在一些情況下他搜索行數(shù)據(jù)對主鍵加鎖的數(shù)量過多，之前也說了innodb加行鎖是最后一起釋放的，所以阻塞了其他讀寫

4、Innodb加鎖的方式是從上到下的

自動加鎖只有表級別的意向鎖和行級鎖，表級別的意向鎖只會阻塞全表掃描

5、RR級別加鎖情況

上文都是基于博主線上環(huán)境配置，如果是RR隔離級別，還會有GapLock與行鎖進(jìn)行Next_keyLock算法加鎖，其實(shí)簡單說就是鎖住當(dāng)前B+樹種當(dāng)前索引到上一個索引之間（或當(dāng)前行到上一行）的間隔，防止在這個過程中有插入數(shù)據(jù)，也就是防止幻讀。

但是這個情況不是絕對的，對于唯一索引，innodb會降低級別行級鎖，不會鎖住范圍

三、總結(jié)

通過以上分析得到結(jié)論：

1、RC級別下innodb都是行級鎖，表級的意向鎖只會阻塞全表掃描

2、innodb不存在鎖升級

3、innodb加不到索引會搜索行，對主鍵加鎖

4、當(dāng)for update一個不存在的where條件時，Innodb加的是Record級別鎖

以上分析除了實(shí)際操作驗證和權(quán)威書籍理解之外，博主與DBA也經(jīng)過深入探討，如果有異議歡迎討論。 另外希望各位同學(xué)，多實(shí)際操作、多看權(quán)威書籍和源碼，對于網(wǎng)上的博客看一半信一半，要有自己的判斷，書籍和源碼的查看也要結(jié)合實(shí)際經(jīng)驗，因為每個人的腦回路是不一樣的，一不小心理解方向就可能歪了。

好了，這些僅為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論