小編給大家分享一下MySQL insert into ... select的死鎖問(wèn)題是什么，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！

創(chuàng)新互聯(lián)專注于望謨企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站,成都商城網(wǎng)站開(kāi)發(fā)。望謨網(wǎng)站建設(shè)公司,為望謨等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站開(kāi)發(fā)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

問(wèn)題產(chǎn)生：

系統(tǒng)中mysql里面有幾個(gè)event，每幾分鐘就會(huì)執(zhí)行一次，用來(lái)統(tǒng)計(jì)數(shù)據(jù)之類的功能，然后這個(gè)event里面會(huì)往一張表里面寫入數(shù)據(jù)。 大致內(nèi)容： replace into a from select 需要的字段 from b; 大體結(jié)構(gòu)是這樣，select 需要的字段from b這里是簡(jiǎn)寫，實(shí)際上非常復(fù)雜，有很多表的join的操作。然后這個(gè)event是每一分鐘就執(zhí)行一次，在數(shù)據(jù)量很大的情況下 一分鐘可能還執(zhí)行不完。然后我們會(huì)有其他的各種插入，更新的操作去對(duì)b表進(jìn)行操作。此時(shí)就會(huì)發(fā)現(xiàn)，后端日志里面經(jīng)常會(huì)有deadlock和wait lock timeout的報(bào)錯(cuò)， 最后測(cè)試發(fā)現(xiàn)把event關(guān)掉就沒(méi)有這個(gè)問(wèn)題，基本確認(rèn)是這個(gè)event的問(wèn)題。

問(wèn)題分析：

其實(shí)最耗時(shí)的是發(fā)現(xiàn)是event的問(wèn)題，查詢資料解決問(wèn)題并沒(méi)有花太多時(shí)間。 1.首先根據(jù)后端日志里面的報(bào)錯(cuò)信息定位到是哪張表產(chǎn)生了死鎖，是哪張表等待鎖超時(shí)
2.然后根據(jù)這幾個(gè)表名和打印的sql找到了大概可能是哪里的問(wèn)題，大致確認(rèn)了是event中的sql導(dǎo)致的
3.再驗(yàn)證我們的想法，把event關(guān)掉后發(fā)現(xiàn)日志就沒(méi)有l(wèi)ock的問(wèn)題了
4.檢查event中的語(yǔ)句發(fā)現(xiàn)大概就是replace into a from select 需要的字段 from b;

這里主要是不太清楚mysql哪些情況會(huì)上鎖，理論上select的操作只會(huì)上一個(gè)共享鎖，對(duì)于b表的插入和更新等操作是上排他鎖， 這兩個(gè)是可以兼容的，一個(gè)讀一個(gè)寫，并不沖突。但是根據(jù)等到所超時(shí)的現(xiàn)象上來(lái)看，就像是select 需要的字段 from b把b表也給鎖住了， 所以插入和更新都在等待鎖。

最后在Stack Overflow中找到了有一點(diǎn)眉目的信息，鏈接地址。 這里說(shuō)要設(shè)置成read-committed的級(jí)別就可以了。然后也引出了一個(gè)mysql配置參數(shù)：innodb_locks_unsafe_for_binlog。

于是我們順著這個(gè)信息從官網(wǎng)上去查看，發(fā)現(xiàn)有這么一段話：

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.復(fù)制代碼

意思是說(shuō)對(duì)于INSERT INTO T SELECT ... FROM S WHERE ...這種情況首先T表上會(huì)家伙是哪個(gè)記錄鎖（行級(jí)鎖），并且是不帶間隙鎖的。 對(duì)于表S，有兩種情況下不會(huì)加鎖：
1.如果事務(wù)隔離級(jí)別為READ COMMITTED
2.或者啟用了innodb_locks_unsafe_for_binlog且事務(wù)隔離級(jí)別不是SERIALIZABLE的

否則，InnoDB在S的行上設(shè)置共享的next-key。如果不清楚next-key的話可以看下官網(wǎng)的這個(gè)介紹，鏈接地址。

因此我們要解決所等待超時(shí)的方式已經(jīng)比較明朗了，就是讓S表不要被鎖住，然而不要被鎖住可以使用官網(wǎng)說(shuō)的兩種方式。 這兩種都可以，但是根據(jù)innodb_locks_unsafe_for_binlog這個(gè)參數(shù)的介紹來(lái)看最好是使用方式1，將事務(wù)的隔離級(jí)別設(shè)置為read-committed。

原因有下面幾點(diǎn)：
1.是innodb_locks_unsafe_for_binlog這個(gè)參數(shù)是靜態(tài)的，必須要在my.cnf中加入一行innodb_locks_unsafe_for_binlog = 1，然后重啟數(shù)據(jù)庫(kù)才能生效。 在mysql中輸入命令：

show variables like "%innodb_locks_unsafe_for_binlog%"復(fù)制代碼

如果發(fā)現(xiàn)是ON就是開(kāi)啟成功了。
2.事務(wù)的隔離級(jí)別粒度比較細(xì)，可以針對(duì)某個(gè)session來(lái)設(shè)置，不同的session可以用不同的隔離級(jí)別，而且這個(gè)參數(shù)是動(dòng)態(tài)的直接在mysql命令行修改就行。
3.mysql5.7的參數(shù)介紹中說(shuō)，innodb_locks_unsafe_for_binlog這個(gè)參數(shù)將在后面的mysql版本中廢棄掉。這個(gè)說(shuō)的是實(shí)話，我去查看了mysql8.0的參數(shù)詳解發(fā)現(xiàn)已經(jīng)沒(méi)有這個(gè)參數(shù)了。

所以推薦使用事務(wù)隔離級(jí)別來(lái)控制。

看完了這篇文章，相信你對(duì)mysql insert into ... select的死鎖問(wèn)題是什么有了一定的了解，想了解更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！