QueryCache聯動內容:http://blog.itpub.net/29510932/viewspace-1694922/
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
案例發生于生產環境，由于是臨時的技術支持，截圖沒有了.....

場景:
MySQL-5.5.47, 隔離級別RR
背景:
業務人員反應數據庫操作時不時出現非常明顯的卡頓, 與此同時慢日志中出現大量的SQL;
問題的現象&排查:
1.先看監控圖表: 發現CPU使用率,IO吞吐量, IO Utils, 網卡in/out流量, 內存的使用率都沒有異常現象----應該不是服務器資源造成的;
2.登錄到生產庫,看一下processlist的情況,并沒有明顯的長連接或者長事務,咨詢了開發人員,在應用層也沒有手動開啟長事務----應該和特殊的SQL或者事務沒什么關系;
3.開發人員反饋并沒有觸發器/存儲過程/定時任務----又排除幾個影響因素;
4.查看了一下當天的慢日志,在某一個隨機的時間點, 會出現很多的慢查詢, 而且慢查詢都是成片成片出現的, 成片出現的慢查詢都有相同的TIMESTAMP----隨機事件,可能是非人為的;
5.這種成片出現的慢查詢, 全部是以Insert, Update這種DML作為前N條;

問題分析:
在排查過程中,初步得出的結論:
可能是SQL的問題; 而且設置的隔離級別是RR, 結合排查的第五點,感覺可能會是鎖等待導致的;
在生產環境查看了一下這些DML表的結構,發現相關的索引都有, 也在測試環境試了一下, 發現這些DML并沒有出現鎖等待的現象;

用mysqldumpslow給某個時間點的近300條慢查詢語句做了個統計, 發現DML語句大約只有10%多一點的樣子,絕大多數還是select;
之后粗略看了一下這些select語句, explain的結果基本都是const, 說明這些語句本身并沒有問題;

在這個過程中,發現一個現象:
這些select語句,約70%都是DML的那幾張表, 而且不論什么類型select語句,記錄下來的時間都是基本一致的,2.78-2.80秒之間;
疑點1:雖然不是很確定這種現象是不是有什么意義, 不過看上去像是由于這幾張表進行了DML, 結果堵住了很多對這幾張表的查詢;
疑點2:除非是IO出現了波動或者峰值/沒有索引/鎖等待, 否則DML語句應該很少會出現在慢查詢日志里面;

猜測是cache或者是buffer的設置問題, 于是去my.cnf檢查一下配置, 然后看到了query_cache_size的設置;query_cache_size=256M
參考聯動內容，其實Query Cache遠沒有發揮想象中作用,不過>=5.6.8和5.7的版本中,query_cache_type默認都是關閉的, 5.5并不太清楚, 難道是這個Query_cache的問題?
翻了一下5.5的文檔,發現query_cache_type的默認值是開啟的, 但是size的默認值是0, 意味著如果什么都不動,那就是屏蔽了Query Cache,
然而配置文件里面修改了size, 所以Query Cache就開啟了;

Query Cache的缺陷,在另一篇博文里面有描述, 對應到這次案例中的疑點1和疑點2， 做出幾個推斷:
在某個時間點內,應用層發起較多的DML,這些DML會嘗試獲取cache中某幾張表的mutex,所以在慢查詢中,在每個時間點,都是最先出現了Insert和Update（互相等待mutex）;
由于Query Cache中,由于相關表的數據被清理，select會重新生成對應的result寫入到Query Cache， 并且還存在并發的DML語句，導致頻繁的在清空和寫入Query Cache;
由于Query Cache設置得比較大,如果保存了大量的數據,那么在獲取mutex, 并清理數據的時候, 也會消耗更多的時間;

聯系運維人員,查看了一下生產庫的Qcache的status，如下圖

可以看到在mysql啟動之后，Qcache觸發了約1.2億次的insert，但是只有約870萬次的緩存命中;
這一組統計數據也基本驗證了Query Cache不好用這一事實;

處理方式:
考慮到Qcache的統計結果,在線上庫關掉應該也不會有什么問題,所以和相關運維人員說明了情況,在最近的維護時間內關掉這個Query Cache,然后觀察一段時間;
反饋結果:
卡頓現象暫時消失了,慢日志也不再出現;
PS:Query Cache的問題多多,除非幾乎沒有DML,否則還是盡量不要開啟的比較好

總結

以上是生活随笔為你收集整理的MySQL案例分析--QueryCache的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。