MySQL Slave 延遲過大優化策略：從架構到硬體的全方位解決方案

MySQL 主從複制中，Slave 落後 Master 是常見痛點。核心原因在於：Master 採用 InnoDB 並發提交事務，而 Slave 傳統上只有單一 SQL 線程回放 Binlog，無法真正並行。加上 MySQL 複制本質是異步（即使半同步也只保證傳到 Slave，不保證提交），延遲在所難免。若 Slave 機器配置更低、甚至跑多實例，問題更嚴重。

核心優化方向

1. 採用真正並行複制的 MariaDB

MariaDB 實作了基於組提交的並行複制（slave_parallel_threads），不受「單庫並行」限制，實測能近乎即時追上 Master。若不想換版本，只能等官方 MySQL 5.7+ 的邏輯時鐘並行複制。

2. 強制所有表顯式定義主鍵

Row 格式下，無主鍵會導致每行更新/刪除觸發全表掃描，大表直接拖垮 Slave。參考案例：主鍵缺失導致備庫 Hang 住。

3. 應用層減輕資料庫負擔

前端用記憶體快取或本地佇列合併讀寫、消除冗餘寫請求，降低 Binlog 產生量。

4. 分庫分表分散複制壓力

避免單庫/單表熱點導致整個實例複制阻塞。

硬體與 OS 層面提升 IOPS 的實戰排序

1. 換 SSD / PCIe SSD：IOPS 提升達傳統 15K SAS 百倍至十萬倍量級。
2. 加大實體記憶體，擴充 InnoDB Buffer Pool：熱數據留在記憶體，減少物理 I/O。
3. 檔案系統改 XFS 或 ReiserFS：高併發下比 ext3/ext4 更穩健（注意剩餘空間 <10% 可能丟數據）。
4. RAID 1+0：SSD 可用 RAID 1 或 RAID 5 + 全域熱備；極致可組 RAID 50。
5. RAID 卡寫入策略設為 WB / FORCE WB：參考陣列卡管理手冊。
6. I/O Scheduler 改 deadline（HDD）或 noop（SSD）：比預設 cfq 提升數倍。

更多技巧歡迎補充！