這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)MySQL慢日志優(yōu)化的案例分析過程，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
最近在分析一個問題的時候，嘗試了很多的方法，算是一個逐步明朗的過程。
首先問題的現(xiàn)象是慢日志報警比較多，這是一套內(nèi)部運維業(yè)務的數(shù)據(jù)庫，涉及兩個獨立的數(shù)據(jù)庫，我們暫且稱為devopsdb(運維管理系統(tǒng)數(shù)據(jù)庫），taskopsdb(任務管理數(shù)據(jù)庫）。
現(xiàn)在報警的是taskopsdb這個數(shù)據(jù)庫。
在開始之前，我先說下整體的環(huán)境和架構(gòu)，數(shù)據(jù)庫版本是5.7.25，使用了MGR架構(gòu)模式，并且略微冒一些，使用了雙活的模式，從業(yè)務上來說，devopsdb和taskopsdb數(shù)據(jù)寫入上是獨立的，所以直接的數(shù)據(jù)沖突可能性幾乎沒有。
devopdb的寫入是實時的，業(yè)務種類比較多，而taskopsdb的寫入相對要少很多，從我的直觀關(guān)鍵，兩者的壓力基本是9:1或者差異更大。
有慢日志了就進行優(yōu)化吧，但是這個慢日志報告讓我有些懵，可以看到里面94%的響應時間是在處理commit的請求。
從慢日志的整體情況可以看到來自于兩個客戶端。
我們直接看下commit相關(guān)的SQL吧，結(jié)果打開一看慢日志文件，基本就是這樣的輸出結(jié)果，既然是慢日志，那么影響的數(shù)據(jù)行數(shù)應該是比較明顯的，但是這里看到“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就報警，所以我們可以入手的一個顯式指標是300個慢日志，如何找到這300個慢查詢，按照近期的報警信息，可以看到這些報警的時間相對是比較固定的，比如晚上22:00，或者早上9:00這樣的時間，所以問題的發(fā)生存在周期性。
基于MGR的方案自身有一些特點，我們暫且先放下，嘉定我們不了解MGR.
兩個節(jié)點的數(shù)據(jù)同步，基本是這樣的場景，taskopsdb的短時間產(chǎn)生了大量的慢日志，而這些慢日志的表現(xiàn)是commit，這個commit的本質(zhì)其實不是taskopsdb里面存在大量的commit操作，而是因為其他原因，導致原本無害的commit操作產(chǎn)生了堆積或者阻塞。所以commit的部分只是表象。
另外兩個節(jié)點的數(shù)據(jù)同步，devopsdb的DML,DDL才會直接影響taskopsdb的負載，也就意味著devopsdb上面的慢日志從表面來看是不會影響taskopsdb的相關(guān)操作的。
順著這個思路，我們往下分析，我下午的時候做了一個大膽的嘗試，那就是從原來的MGR的模式降級為異步雙主的模式，結(jié)果就好像潮水褪去一樣，這些慢日志都付出水面了。
也就意味著根本的慢日志就是taskopsdb上面的兩類不起眼的慢日志，修復了索引之后，這個問題就沒有出現(xiàn)，當然這個問題的反思還在進行中。
上述就是小編為大家分享的MySQL慢日志優(yōu)化的案例分析過程了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道。
重慶分公司
重慶分公司
