mysql insert into ... select的鎖問題

引語：

最近中遇到一個資料庫死鎖的問題，這裡記錄一下解決的過程。

問題產生：

系統中mysql裡面有幾個event，每幾分鐘就會執行一次，用來統計資料之類的功能，然後這個event裡面會往一張表裡面寫入資料。
大致內容：
replace into a from select 需要的欄位 from b;
大體結構是這樣，select 需要的欄位from b這裡是簡寫，實際上非常複雜，有很多表的join的操作。然後這個event是每一分鐘就執行一次，在資料量很大的情況下
一分鐘可能還執行不完。然後我們會有其他的各種插入，更新的操作去對b表進行操作。此時就會發現，後端日誌裡面經常會有deadlock和wait lock timeout的報錯，
最後測試發現把event關掉就沒有這個問題，基本確認是這個event的問題。

問題分析：

其實最耗時的是發現是event的問題，查詢資料解決問題並沒有花太多時間。
1.首先根據後端日誌裡面的報錯資訊定位到是哪張表產生了死鎖，是哪張表等待鎖超時
2.然後根據這幾個表名和列印的sql找到了大概可能是哪裡的問題，大致確認了是event中的sql導致的
3.再驗證我們的想法，把event關掉後發現日誌就沒有lock的問題了
4.檢查event中的語句發現大概就是replace into a from select 需要的欄位 from b;

這裡主要是不太清楚mysql哪些情況會上鎖，理論上select的操作只會上一個共享鎖，對於b表的插入和更新等操作是上排他鎖，
這兩個是可以相容的，一個讀一個寫，並不衝突。但是根據等到所超時的現象上來看，就像是select 需要的欄位 from b把b表也給鎖住了，
所以插入和更新都在等待鎖。

最後在Stack Overflow中找到了有一點眉目的資訊，連結地址。
這裡說要設定成read-committed的級別就可以了。然後也引出了一個mysql配置引數：innodb_locks_unsafe_for_binlog。

於是我們順著這個資訊從官網上去檢視，發現有這麼一段話：

INSERT INTO T SELECT ... FROM S WHERE ... sets an exclusive index record lock (without a gap lock) on each row inserted into T. If the transaction isolation level is READ COMMITTED, or innodb_locks_unsafe_for_binlog is enabled and the transaction isolation level is not SERIALIZABLE, InnoDB does the search on S as a consistent read (no locks). Otherwise, InnoDB sets shared next-key locks on rows from S. InnoDB has to set locks in the latter case: During roll-forward recovery using a statement-based binary log, every SQL statement must be executed in exactly the same way it was done originally.

意思是說對於INSERT INTO T SELECT … FROM S WHERE …這種情況首先T表上會傢伙是哪個記錄鎖（行級鎖），並且是不帶間隙鎖的。
對於表S，有兩種情況下不會加鎖：
1.如果事務隔離級別為READ COMMITTED
2.或者啟用了innodb_locks_unsafe_for_binlog且事務隔離級別不是SERIALIZABLE的

否則，InnoDB在S的行上設定共享的next-key。如果不清楚next-key的話可以看下官網的這個介紹，連結地址。

因此我們要解決所等待超時的方式已經比較明朗了，就是讓S表不要被鎖住，然而不要被鎖住可以使用官網說的兩種方式。
這兩種都可以，但是根據innodb_locks_unsafe_for_binlog這個引數的介紹來看最好是使用方式1，將事務的隔離級別設定為read-committed。

原因有下面幾點：
1.是innodb_locks_unsafe_for_binlog這個引數是靜態的，必須要在my.cnf中加入一行innodb_locks_unsafe_for_binlog = 1，然後重啟資料庫才能生效。
在mysql中輸入命令：

show variables like "%innodb_locks_unsafe_for_binlog%"

如果發現是ON就是開啟成功了。
2.事務的隔離級別粒度比較細，可以針對某個session來設定，不同的session可以用不同的隔離級別，而且這個引數是動態的直接在mysql命令列修改就行。
3.mysql5.7的引數介紹中說，innodb_locks_unsafe_for_binlog這個引數將在後面的mysql版本中廢棄掉。這個說的是實話，我去檢視了mysql8.0的引數詳解發現已經沒有這個引數了。

所以推薦使用事務隔離級別來控制。

參考資料：

1.Stack Overflow上對於insert select鎖的解答
2.innodb鎖設定的情況
3.innodb所種類介紹
4.innodb_locks_unsafe_for_binlog引數的介紹