MySQL慢日志優(yōu)化的案例分析過程

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)MySQL慢日志優(yōu)化的案例分析過程，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

最近在分析一個問題的時候，嘗試了很多的方法，算是一個逐步明朗的過程。

首先問題的現(xiàn)象是慢日志報警比較多，這是一套內(nèi)部運維業(yè)務(wù)的數(shù)據(jù)庫，涉及兩個獨立的數(shù)據(jù)庫，我們暫且稱為devopsdb(運維管理系統(tǒng)數(shù)據(jù)庫），taskopsdb(任務(wù)管理數(shù)據(jù)庫）。

現(xiàn)在報警的是taskopsdb這個數(shù)據(jù)庫。

在開始之前，我先說下整體的環(huán)境和架構(gòu)，數(shù)據(jù)庫版本是5.7.25，使用了MGR架構(gòu)模式，并且略微冒一些，使用了雙活的模式，從業(yè)務(wù)上來說，devopsdb和taskopsdb數(shù)據(jù)寫入上是獨立的，所以直接的數(shù)據(jù)沖突可能性幾乎沒有。

devopdb的寫入是實時的，業(yè)務(wù)種類比較多，而taskopsdb的寫入相對要少很多，從我的直觀關(guān)鍵，兩者的壓力基本是9:1或者差異更大。

有慢日志了就進(jìn)行優(yōu)化吧，但是這個慢日志報告讓我有些懵，可以看到里面94%的響應(yīng)時間是在處理commit的請求。

從慢日志的整體情況可以看到來自于兩個客戶端。

我們直接看下commit相關(guān)的SQL吧，結(jié)果打開一看慢日志文件，基本就是這樣的輸出結(jié)果，既然是慢日志，那么影響的數(shù)據(jù)行數(shù)應(yīng)該是比較明顯的，但是這里看到“Rows_examined”和“Rows_sent"都是0，但是很直白的是commit的執(zhí)行時間依舊很長。

問題到了這里似乎有些兩難，想優(yōu)化但是苦于沒有太直接有效的信息，在把整個慢日志梳理了一遍之后，我開始關(guān)注那5%的慢日志信息，發(fā)現(xiàn)確實有幾個表的掃描代價太高了，算是一個優(yōu)化點。

做完優(yōu)化之后，發(fā)現(xiàn)報警頻率確實少了很多，但是問題依舊存在。每次收到這樣的報警信息，總是讓人感覺到不舒服。

于是我開始想有沒有其他的思路和方法。

我們從報警入手，報警的閾值是統(tǒng)計慢日志條數(shù)超過300就報警，所以我們可以入手的一個顯式指標(biāo)是300個慢日志，如何找到這300個慢查詢，按照近期的報警信息，可以看到這些報警的時間相對是比較固定的，比如晚上22:00，或者早上9:00這樣的時間，所以問題的發(fā)生存在周期性。

基于MGR的方案自身有一些特點，我們暫且先放下，嘉定我們不了解MGR.

兩個節(jié)點的數(shù)據(jù)同步，基本是這樣的場景，taskopsdb的短時間產(chǎn)生了大量的慢日志，而這些慢日志的表現(xiàn)是commit，這個commit的本質(zhì)其實不是taskopsdb里面存在大量的commit操作，而是因為其他原因，導(dǎo)致原本無害的commit操作產(chǎn)生了堆積或者阻塞。所以commit的部分只是表象。

另外兩個節(jié)點的數(shù)據(jù)同步，devopsdb的DML,DDL才會直接影響taskopsdb的負(fù)載，也就意味著devopsdb上面的慢日志從表面來看是不會影響taskopsdb的相關(guān)操作的。

順著這個思路，我們往下分析，我下午的時候做了一個大膽的嘗試，那就是從原來的MGR的模式降級為異步雙主的模式，結(jié)果就好像潮水褪去一樣，這些慢日志都付出水面了。

也就意味著根本的慢日志就是taskopsdb上面的兩類不起眼的慢日志，修復(fù)了索引之后，這個問題就沒有出現(xiàn)，當(dāng)然這個問題的反思還在進(jìn)行中。

上述就是小編為大家分享的MySQL慢日志優(yōu)化的案例分析過程了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。