【問題】

INSERT語句是最常見的SQL語句之一，最近有臺MySQL伺服器不定時的會出現併發執行緒的告警，從記錄資訊來看，有大量insert的慢查詢，執行幾十秒，等待flushing log，狀態query end

【初步分析】

從等待資源來看，大部分時間消耗在了innodb_log_file階段，懷疑可能是磁碟問題導致，經過排查沒有發現伺服器本身存在硬體問題

後面開啟執行緒上升時pstack的自動採集，定位MySQL執行緒等待的位置。

【分析過程】

部署了pstack的自動抓取後，出現過6次thread concurrency >=50的告警（每次告警時會有大量的慢查詢產生），有3次抓到了現場。

併發執行緒升高時，有50多個執行緒卡在Stage_manager::enroll_for函式，處於group commit階段

執行緒0x519c5940對應的SQL語句如下，已經執行18秒

Stage_manager::enroll_for函式的作用實現了多個執行緒在flush_stage階段的排隊。簡單來說，對於一個分組的事務，是被leader執行緒去提交的，其他執行緒處於排隊等待狀態，等待leader執行緒將該執行緒的事務提交完成。

如果第一個執行緒執行慢，後面的執行緒都處於等待狀態，整組事務無法提交。

流程也可以理解如下，

Session A COMMIT-->拿到鎖-->進行binlog寫-->commit完成

Session B COMMIT-->等待鎖--------------------------->拿到鎖-->進行binlog寫-->commit完成

第一個執行緒為什麼執行很慢，分析了發生告警時間段的日誌檔案，發現日誌中存在2個15M和20M的大事務

檢視日誌明細，存在delete from的大事務刪除語句，約包含23W條記錄，ROW模式下刪除23W條記錄，會產生大約20M的日誌檔案，刷盤時間較長，阻塞了同一個分組下其他事務的提交。

事務的開始時間與告警時間吻合

積壓的分組下事務集中刷盤，反應到磁碟指標上可以看到在問題時間段的disk_write_kbytes指標出現明顯的上升

【優化方案】

1、 建議開發避免使用delete from 整表的大事務刪除語句

【其他變通方案】

2、 Binlog 記錄的ROW模式下會產生大量的日誌，改為MIXED模式，理論上也可以解決問題

3、 更換效能好的磁碟

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對我們的支援。