數(shù)據(jù)準(zhǔn)備：
create table t(c1 int primary key, c2 int, c3 int, c4 int, unique index i_c2(c2), index i_c3(c3));
insert into t values (10, 11, 12, 13), (20, 21, 22, 23), (30, 31, 32, 33), (40, 41, 42, 43);
表名t，c1列為主鍵，c2列為唯一索引，c3列為普通索引
數(shù)據(jù)庫隔離級(jí)別：RR
數(shù)據(jù)庫版本：mysql 5.7.21
鎖阻塞示意圖(后續(xù)分析的時(shí)候，用得到)：
image.png
死鎖場(chǎng)景
場(chǎng)景說明：批量插入場(chǎng)景，多個(gè)會(huì)話同時(shí)插入，每一個(gè)會(huì)話插入多條數(shù)據(jù)。
場(chǎng)景描述：在唯一索引c2的間隙（31，41）插入3條不同記錄。會(huì)話1先插入1條c2=36，會(huì)話2接著插入1條c2=35，最后會(huì)話1插入1條c2=34。這3次操作插入的值都不一樣
會(huì)話1：
start transaction;
insert into t values(50,36,52,53) on duplicate key update c2=36;
會(huì)話2：
start transaction;
insert into t values(60,35,62,63) on duplicate key update c2=35;
這個(gè)時(shí)候會(huì)話2阻塞了，我們可以查看一下鎖信息
另外開啟一個(gè)會(huì)話3
show engine innodb status;
image.png
暫不分析這個(gè)鎖信息，后面一起分析
接著，會(huì)話1：
insert into t values(70,34,72,73) on duplicate key update c2=34;
這個(gè)時(shí)候某一個(gè)會(huì)話會(huì)顯示如下信息：
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
我們切換到會(huì)話3
show engine innodb status;
image.png
可以看到最新的1條死鎖信息，就是我們剛剛產(chǎn)生的死鎖
分析：
說在前面：第一張圖命名為圖1，第二張圖命名為圖2
一. 查看圖1，我們知道insert會(huì)上3把鎖
1.1 表鎖IX，這個(gè)沒有任何問題，插入期間，表結(jié)構(gòu)不能變
1.2 間隙鎖（lock_model X locks gap before rec）,這個(gè)比較難理解。我看了半天原因也沒看明白想。（如果insert語句命中了記錄，比如已經(jīng)存在c2=36的記錄，這里會(huì)是next-key lock）如果你想細(xì)細(xì)研究，參考如下文章https://juejin.im/entry/5adca48df265da0b9c1037c8
總之，因?yàn)閙ysql5.6有一個(gè)bug，mysql5.7為了修復(fù)這個(gè)bug，引入了這把鎖
1.3 插入意向鎖（lock_mode X locks gap before rec insert intention waiting）,插入的時(shí)候，一般都有這把鎖。目的是，告訴別人我要在某某區(qū)間插入數(shù)據(jù)了，避免幻讀(RC隔離級(jí)別不會(huì)加，這里我80%的把握，如果RC隔離級(jí)別會(huì)加，還望大神指正)。對(duì)意向鎖感興趣，可以參考如下文章：http://yeshaoting.cn/article/database/mysql%20insert%E9%94%81%E6%9C%BA%E5%88%B6/
1.4 還有最后一個(gè)紅框，是lock_mode X locks rec but not gap 這個(gè)是插入記錄之后的記錄鎖。
這里捋一下：
會(huì)話1插入記錄的時(shí)候，申請(qǐng)表鎖IX，gap鎖，插入意向鎖。插入成功后，釋放了插入意向鎖，增加了插入記錄的記錄鎖（rec lock）（理論上鎖在事務(wù)未提交，不應(yīng)該釋放，但是看截圖是釋放了的，估計(jì)記錄鎖也能夠保證插入意向鎖的功能）
會(huì)話2插入記錄的時(shí)候，申請(qǐng)表鎖IX，gap鎖。然后申請(qǐng)意向鎖發(fā)生了等待，因?yàn)闀?huì)話1持有了gap鎖。
二. 查看圖2，我們可以看到死鎖原因
會(huì)話2總共3把鎖，等待插入意向鎖，另外持有的2把鎖沒有顯示，經(jīng)過圖1的分析，可以猜到是表鎖IX和間隙鎖gap lock。
會(huì)話1持有3把鎖，等待1把鎖。持有表鎖IX，gap鎖，第一條插入記錄的record lock鎖（第一條記錄申請(qǐng)的插入意向鎖已經(jīng)釋放）
會(huì)話1插入第三條記錄的時(shí)候，先申請(qǐng)gap鎖，發(fā)現(xiàn)已經(jīng)持有，成功（我猜的）。申請(qǐng)插入意向鎖發(fā)生了等待，因?yàn)闀?huì)話2持有g(shù)ap鎖，阻塞了插入意向鎖。
總之，死鎖產(chǎn)生原因是，會(huì)話2的插入意向鎖等待會(huì)話1釋放gap鎖，會(huì)話1插入意向鎖也在等待會(huì)話2釋放gap鎖。
三. 如何規(guī)避
- 隔離級(jí)別調(diào)整為RC，讀提交，在這種場(chǎng)景不會(huì)有g(shù)ap鎖（并不是說RC隔離級(jí)別不會(huì)有g(shù)ap鎖）。前提是binlog同步機(jī)制是基于row，而不是基于statement。這一塊不熟悉的，可以參考
http://www.itdecent.cn/p/c16686b35807
這里多說一句，建議大家都把隔離級(jí)別調(diào)整為RC，然后binlog基于row。這樣能夠減少很多死鎖的發(fā)生（因?yàn)樗梨i一般是因?yàn)間ap鎖，而RR隔離級(jí)別很多場(chǎng)景都會(huì)有g(shù)ap鎖。而RC隔離級(jí)別只有很少場(chǎng)景存在gap鎖） - 改寫為先select 如果存在update，不存在insert
