【問題】
有台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、 更換性能好的磁盤
