【問題】

有臺MySQL 5.6.21的資料庫例項以寫入為主，IO %util接近100%

寫入IOPS很高

【分析過程】

1、通過iotop工具可以看到當前IO消耗最高的mysql執行緒

2、檢視執行緒49342的堆疊，可以看到正在進行redo log的重新整理，對應的是9號檔案

3、9號檔案對應的是redo log的第一個檔案

為什麼mysql程序會頻繁的重新整理redo log檔案，要結合redolog的刷盤策略來分析，關鍵是innodb_flush_log_at_trx_commit引數，

預設是1，最安全，但在寫壓力大的情況下，也會帶來較大的效能影響，每次事務提交時MySQL都會把log buffer的資料寫入log file，並且flush(刷到磁碟)中去。

 結合這個叢集的寫入場景來看，大部分都是小事務的寫入，每次事務提交都會觸發刷盤動作，這種場景下通過增大innodb_log_buffer_size和innodb_log_file_size的優化效果不明顯

【優化方案】

1、應用層面，對於寫壓力大的系統，可以將單條的insert語句優化為小批量的insert語句，這樣事務commit的次數減少，redo log刷盤減少，效能理論上會有提升

2、MySQL層面，對於日誌型別的系統，如果允許宕機的情況下少量資料丟失，可以將innodb_flush_log_at_trx_commit引數調整為2，

當設定為2時，則在事務提交時只做write操作，只保證寫到系統的page cache，因此例項crash不會丟失事務，但宕機則可能丟失事務

在這臺伺服器上測試，將引數調整為2時，IO的請求從200M/S降到約10M/S壓力會減少10倍以上

3、系統層面，更換效能更佳的磁碟