#最近遇到一個資料庫死鎖的問題，這裡記錄解決的過程。
系統中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的參數詳解發現已經沒有這個參數了。
所以建議使用交易隔離等級來控制。
更多相關免費學習推薦：mysql教學##(影片)
#
以上是認識mysql insert into ... select的鎖問題的詳細內容。更多資訊請關注PHP中文網其他相關文章！
