MySQL 所在服務器使用命令iostat -xd 1 查看遵岩，其中一個盤的 %uitl 一直在 80%意敛，但是讀寫速率又不高，寫延遲也不大立轧。
雖然 util 只是代表了繁忙程度格粪，并不能直接代表硬盤的性能。但是看著數(shù)值這么高氛改，不順心帐萎，并且報警也會一直有。所以進行了分析處理
從 iostat 上看胜卤，讀速率幾乎為 0疆导，寫 4MB+/s（磁盤最高支持最高 350MB/s），iops 也只有 600 多葛躏，遠沒有達到磁盤 11,800 的上限澈段。
懷疑兩個問題
- update、insert 任務太多舰攒，導致寫請求分散
- binlog 寫頻率過高
針對問題 1 修改了 innodb_io_capacity（變量定義了InnoDB后臺任務每秒可用的 IOPS 數(shù)量败富，默認是 200）和 innodb_io_capacity_max (默認 2000)
SET GLOBAL innodb_io_capacity = 5000;
SET GLOBAL innodb_io_capacity_max = 8000;
修改后沒有效果。
然后針對問題 2 摩窃，修改了
sync_binlog用來配置合并多少條binlog一次性寫入磁盤兽叮，默認為 1
set global sync_binlog=50;
修改完畢之后 磁盤IO使用率馬上降了下來。可以確定是由于多個事務同時提交充择，導致刷新 binlog 造成的IO使用率過高德玫。
但是目前的修改有個風險是如果服務器宕機，從庫會丟失部分數(shù)據(jù)椎麦。算是安全和性能的取舍了宰僧。
