核心原因：單線程 Replay 追不上 Master 並發
Master 多線程並發提交，Slave 只有單一 SQL Thread 重放 Binlog（即使 5.6+ 多線程復制僅支持庫級並行），高並發下延遲不可避免。加上異步復制本質、Slave 機器配置往往低於 Master，延遲進一步放大。
七大優化方向（按收益遞減排序）
- 存儲升級：SSD / PCIe SSD / NVMe
IOPS 提升 100~100,000 倍於 15K SAS，直接消除 I/O 瓶頸，收益最大。
- 加大內存，擴大 InnoDB Buffer Pool
熱數據全內存，減少物理讀，間接降低 Redo Log 刷盤壓力。
- 文件系統調優：XFS 或 ReiserFS
高 IOPS 下優於 ext3/ext4，穩定性更好（注意預留 >10% 磁盤空間防 XFS 潛在問題）。
- RAID 級別：RAID 10 (1+0)
讀寫性能最佳。全 SSD 可用 RAID 1 (兩盤) 或 RAID 5/50 + 全局熱備。
- RAID 卡寫策略：Write Back (WB) 或 Force WB
利用卡上緩存加速寫入，需配備 BBU/FBWM 防斷電丟數據。
- I/O 調度器：Deadline / NOOP
HDD 用 Deadline，SSD 用 NOOP，比默認 CFQ 提升數倍 IOPS。
架構層面補充建議
- 升級 MySQL 5.7+ 使用 MTS (Multi-Threaded Slave)，配合
slave_parallel_type=LOGICAL_CLOCK 實現真正並行重放。
- 啟用 半同步復制 減少數據丟失窗口。
- Slave 機器規格不低於 Master，避免跑多實例爭搶資源。
總結
Slave 延遲本質是「單線程重放 vs 多線程產生」的速度差。硬件升級（SSD、內存、RAID、內核）是治本，架構升級（MTS、半同步）是治標，兩手都要硬。
