#最近遇到一個資料庫死鎖的問題,這裡記錄解決的過程。
系統中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中文網其他相關文章!