AFTER_SYNC比AFTER_COMMIT更安全，因主库在binlog刷盘后才等待从库ACK，事务未提交前宕机可回滚，避免数据丢失；而AFTER_COMMIT先提交再等ACK，主库宕机易导致已提交事务未同步而丢数据。
设置 rpl_semi_sync_master_wait_point 不能直接“提高性能”，它影响的是数据安全边界和事务阻塞时机——选错值反而会放大丢失风险或拖慢吞吐。
为什么 AFTER_SYNC 比 AFTER_COMMIT 更安全
主库提交事务时有两个关键节点：写入 binlog 并刷盘（AFTER_SYNC 点），以及真正提交事务（AFTER_COMMIT 点）。rpl_semi_sync_master_wait_point 决定主库在哪个点等从库 ACK。
-
AFTER_SYNC：主库把 binlog 刷到磁盘后，就暂停并等待至少一个从库写入 relay log 的 ACK。此时事务尚未提交，若主库宕机，该事务可回滚，不会造成主从不一致 -
AFTER_COMMIT：主库先提交事务、释放锁、返回客户端成功，再等 ACK。如果此时网络中断或从库未响应，而主库又立即宕机，该事务已提交但未同步，切换到从库后就会丢数据
MySQL 5.7+ 默认是 AFTER_SYNC，5.6 及更早默认是 AFTER_COMMIT。除非你明确接受“主库单点故障下可能丢事务”的风险，否则不要切回 AFTER_COMMIT。
rpl_semi_sync_master_wait_point 不是性能调优参数
它不控制延迟、不调节吞吐、也不影响并发数。它的作用纯粹是定义“半同步”的语义边界。所谓“性能差异”其实是副作用：
- 在高负载 + 高延迟网络下，
AFTER_COMMIT表面看更快（客户端返回早），但掩盖了数据未落盘的风险 -
AFTER_SYNC会让单个事务多等一次网络往返（binlog 刷盘 → 等 ACK → 提交），但避免了故障场景下的数据修复成本，长期看更稳 - 如果观察到
Rpl_semi_sync_master_status频繁为OFF，问题大概率出在rpl_semi_sync_master_timeout过小或从库 IO 压力大，而不是这个参数设错了
实际配置时必须检查的三件事
光改 rpl_semi_sync_master_wait_point 没用，它依赖底层协同生效：
- 主库和从库都必须已安装并启用对应插件：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'和INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so' - 从库的
relay_log必须开启且能及时刷盘；如果从库sync_relay_log = 0或磁盘慢，ACK 就会延迟，导致主库频繁超时降级 - 主库参数
rpl_semi_sync_master_enabled = ON和rpl_semi_sync_master_timeout（建议 1000–3000ms）必须同时生效，否则wait_point不起作用
最容易被忽略的是：即使设了 AFTER_SYNC，如果从库没真正把事件写进 relay log（比如 relay log 满、磁盘只读、SQL 线程卡住），主库照样收不到 ACK，最终还是降级成异步。所以别只盯着这个参数调，得看 Rpl_semi_sync_master_no_times 和 Rpl_semi_sync_master_off_times 这两个状态变量是否在持续增长。
