今天分析了另外一個關于數(shù)據(jù)庫延遲跳動的問題，也算是比較典型，這個過程中也有一些分析問題的方法和技巧工參考。

首先在高可用檢測中，有一套環(huán)境的檢測時斷時續(xù)，經(jīng)過排查發(fā)現(xiàn)是數(shù)據(jù)庫產(chǎn)生了延遲，在登錄到從庫show slave status查看，會發(fā)現(xiàn)Seconds_behind_master的值是不斷跳動的，即從0~39~0~39這樣的頻率不斷跳動，讓人很搓火。

查看數(shù)據(jù)庫的相關日志發(fā)現(xiàn)竟然沒有任何可以參考的日志記錄，怎么分析這個問題呢，我們先來復現(xiàn)，于是我按照節(jié)奏抓取了3次問題出現(xiàn)的日志，即通過show slave status連續(xù)監(jiān)測，抓取show slave status輸出的結果保存下來，這樣我們就得到了一個問題發(fā)生過程中的偏移量變化，而這個變化則是在SQLThread在回放過程中產(chǎn)生的問題。

比如下面的一段輸出，我截取的是Slave端的relay log進行分析，相應的字段為Relay_Log_Pos

所以很快得到了偏移量的變化情況：385983806 ，386062813 ，386125580

接著我使用mysqlbinlog開始分析這些日志過程中的明細，根據(jù)如下的命令可以很快得到轉儲的日志中相關的表有3張。

我逐步分析了每張表的數(shù)據(jù)操作情況，得到的信息還是比較有限，繼續(xù)做更進一步的分析，比如我們分析一下整個日志中的事務量大?。?/p>

可以看到是5K左右，算是比較大了，而這些額外的信息從哪里獲得呢，我在主庫開啟了general_log，這樣就能夠得到更細粒度的操作日志了。

進一步分析發(fā)現(xiàn)，整個業(yè)務使用了顯示事務的方式：SET autocommit=0，整個事務中包含了幾個大SQL，里面存儲了很多操作日志明細，而且在事務操作過程中還基于Mybatis框架調用了多次select count（1） from xxx的操作。

經(jīng)過和業(yè)務溝通也基本明確了以上問題。