這篇文章主要講解了“MySQL LOCKS監(jiān)控的詳細(xì)介紹”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“MYSQL LOCKS監(jiān)控的詳細(xì)介紹”吧！

創(chuàng)新互聯(lián)公司10多年成都定制網(wǎng)頁(yè)設(shè)計(jì)服務(wù);為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì)及高端網(wǎng)站定制服務(wù),成都定制網(wǎng)頁(yè)設(shè)計(jì)及推廣,對(duì)成都花箱等多個(gè)行業(yè)擁有豐富的網(wǎng)站維護(hù)經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。

MYSQL 性能問(wèn)題中，一定包含 LOCKS 的問(wèn)題，我想沒(méi)人反對(duì)，但如何監(jiān)控他，其實(shí)說(shuō)句實(shí)話，沒(méi)有看到特別多的好的解決方法。有兩個(gè)極端，一個(gè)是本身在MYSQL上的程序本身基礎(chǔ)打得好，所以MYSQL 基本上很少有DEAD LOCKS , 另外一個(gè)，恐怕是根本使用MYSQL的人就不知道怎么監(jiān)控DEAD LOCK ，所以沒(méi)有意識(shí)到這個(gè)問(wèn)題。

首先死鎖的檢測(cè)默認(rèn)是被打開(kāi)的，并且INNODB 是自動(dòng)的檢測(cè)事務(wù)的私說(shuō)，自動(dòng)的會(huì)館或者自動(dòng)終結(jié)私說(shuō)，innodb會(huì)嘗試選擇較小的事務(wù)去進(jìn)行roll back,根據(jù) DML操作中的事務(wù)的尺寸來(lái)進(jìn)行判斷。

相對(duì)來(lái)說(shuō)如果你的 innodb_table_locks  = 1  并且autocommit = 0的情況下，那解決私說(shuō)的問(wèn)題就只能動(dòng)用 innodb_lock_wait_timeout 這個(gè)參數(shù)了，或祈求GOD help.

當(dāng)然如果你關(guān)閉了innodb_deadlock_detect 這個(gè)參數(shù)，那你的死鎖也是無(wú)法被檢測(cè)到的，另外 innodb_lock_wait_timeout 這個(gè)參數(shù)的設(shè)置，就可以看出掌握這個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的人員是否老道。

死鎖的成因如果解釋起來(lái)，簡(jiǎn)單的解釋就是  session a  掌握了資源 a ,但在處理事務(wù)的時(shí)候，不光需要a ,還需要資源b, 而 session b  掌握了資源b，而處理時(shí)不光需要b ,還需要a, 但不幸的是，在同一個(gè)時(shí)間，session 掌握了a ,去提取b , 而 session b 掌握了b 去提取a ,也不知道是 session a 最后拿到了 資源b 而解鎖，還是session b 拿到了 a而解鎖，最后MYSQL系統(tǒng)滴滴答答吹喇叭。 好吧不要打我，最后的結(jié)果就是一個(gè)事務(wù)被回滾，系統(tǒng)記錄錯(cuò)誤信息。

所以監(jiān)控dead locks 或 locks 其實(shí)是很重要的一件事

1 你知道那個(gè)語(yǔ)句和那個(gè)語(yǔ)句發(fā)生了死鎖

2 你知道是否有挽救的可能性

如果入行久了，馬上的反映就是 show engine innodb status 去查看死鎖，是這就是mysql 5.x （5.6之前）的方法， 并且很好用。（不知道，那你還是百度一下吧）。

現(xiàn)在進(jìn)行LOCKS(不光是死鎖，包括類似blocked 的信息)的監(jiān)控，一般都需要使用 performance_schema來(lái)進(jìn)行，（什么性能損失，你是有多缺錢，多加一點(diǎn)CPU, 內(nèi)存你會(huì)死嗎，浪費(fèi)5% -10%的性能，換你老板問(wèn)你為什么的時(shí)候，你能痛快的寫(xiě)出報(bào)告，還是只能瞎編，你自己看著辦）。

怎么做，很多種方法，我們先來(lái)說(shuō)說(shuō)傳統(tǒng)的方法

1 innodb_print_all_deadlocks 

這個(gè)參數(shù)你要打開(kāi)喲，否則你真的只能傻乎乎去看 show engine innodb sttatus , 并且如果發(fā)生很多死鎖，那你會(huì)遺漏的信息會(huì)很多。同時(shí)打開(kāi)這個(gè)參數(shù)還可以在ERROR log 中看到相關(guān)的所有的死鎖信息。

2 確認(rèn)你的wait/lock/metadata/sql/mdl 要打開(kāi)， 然后你就可以去查看

你的metadata_locks 表，當(dāng)然如果你還知道 threads，那你可以聯(lián)合這兩個(gè)tables 來(lái)將那兩個(gè)語(yǔ)句之間進(jìn)行了，那個(gè)session 和 那個(gè)session之間的矛盾，以及相關(guān)的語(yǔ)句會(huì)一目了然。

SELECT

    performance_schema.threads.PROCESSLIST_ID,

    performance_schema.metadata_locks.*

FROM

performance_schema.threads,

    performance_schema.metadata_locks

WHERE

performance_schema.threads.THREAD_ID =performance_schema.metadata_locks.OWNER_THREAD_ID;

3 PT 工具 或者自己寫(xiě)一個(gè)腳本，來(lái)自動(dòng)記錄可能發(fā)生的死鎖。

例如我們可以通過(guò) pt-deadlock-logger 來(lái)進(jìn)行相關(guān)的死鎖鑒定

4 動(dòng)態(tài)的查看innodb的 deadlock 數(shù)，可以進(jìn)行動(dòng)態(tài)的監(jiān)控，尤其在新上項(xiàng)目后，或者硬件變動(dòng)后可以第一時(shí)間發(fā)現(xiàn)問(wèn)題。當(dāng)然你需要先將 innodb_locks  和 innodb_lock_waits 這兩個(gè)表搞搞清楚

感謝各位的閱讀，以上就是“MYSQL LOCKS監(jiān)控的詳細(xì)介紹”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)MYSQL LOCKS監(jiān)控的詳細(xì)介紹這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！