傳統半同步流程：
核心問題：Dump 線程串行化「發送」與「等待 ACK」，高並發下成為 TPS 瓶頸。
5.7.4+ 引入專門的 ACK Collector 線程：
效能提升：高並發場景下 TPS 顯著提升，主庫不再因網絡 RTT 阻塞發送管道。
新參數 rpl_semi_sync_master_wait_point 兩個可選值：
| 值 | 行為 | 資料安全性 | 效能 |
|---|---|---|---|
| AFTER_SYNC (默認) | 寫 Binlog → 同步磁盤 → 發送 Slave → 等待 ACK → **主庫提交事務** → 返回客戶端 | 最高：主庫 Crash 時，所有已提交事務必在 Slave Relay Log | 稍低（多一次 fsync 等待） |
| AFTER_COMMIT | 寫 Binlog → 發送 Slave → **主庫提交事務** → 等待 ACK → 返回客戶端 | 較低：主庫 Crash 後切換至 Slave，可能丟失「已提交主庫但未應用 Slave」的事務 | 較高（提交不阻塞於 ACK） |
AFTER_SYNC，資料零容忍丟失AFTER_COMMIT 換取吞吐，需業務接受「極低概率主從切換後數據不一致」Rpl_semi_sync_master_wait_sessions、Rpl_semi_sync_master_yes_tx/no_txLOCK_log 衝突rpl_semi_sync_master_wait_point=AFTER_SYNC（默認）符合業務 SLASHOW PROCESSLIST 可見 Binlog Dump 與 Semi-sync ACK receiver
