半同步复制让主库写入变慢，是因为主库必须等待至少一个从库返回ACK（写入relay log并刷盘）后才提交事务；默认超时10000ms过长，应调至100–500ms，并确保从库磁盘IO、网络RTT及多线程复制配置合理。
开启半同步复制后主库事务变慢，不是配置错了，而是它本来就要等从库确认——但这个等待可以压到毫秒级，关键在调参和规避隐性阻塞。
为什么半同步会让主库写入变慢
半同步不是“加个插件就完事”，它强制主库在 COMMIT 返回前，必须收到至少一个从库的 ACK。如果从库响应慢、网络抖动、或 ACK 超时未达，主库会退化为异步模式（Rpl_semi_sync_master_status 变 OFF），但更常见的是：主库卡在等待，innodb_lock_wait_timeout 没到，但用户侧已感知延迟。
典型现象：SHOW PROCESSLIST 里看到大量线程停在 Waiting for semi-sync ACK from slave；监控里 QPS 下降、commit_latency 突增。
- 从库磁盘写 relay log 慢（比如用 SATA 盘），ACK 就晚
- 主从间网络 RTT > 10ms，尤其跨机房部署时
-
rpl_semi_sync_master_timeout设太高（默认 10000ms），主库傻等 - 从库 SQL 线程积压，IO 线程虽收到 binlog，但 ACK 发不出（ACK 在 IO 线程收到并落盘后才发）
rpl_semi_sync_master_timeout 必须调低
这个参数决定主库最多等多久。设成 10000（默认值）等于允许主库卡 10 秒，业务根本扛不住。它不是“超时才退化”，而是“超时即退化并继续提交”，所以应设成你能容忍的最长等待——通常 50–200ms 足够。
- 执行：
SET GLOBAL rpl_semi_sync_master_timeout = 100;（单位毫秒） - 写进配置文件：
rpl_semi_sync_master_timeout = 100 - 低于 50ms 风险高：小抖动就频繁退化；高于 500ms 用户明显感知卡顿
- 改完立刻生效，无需重启 MySQL
从库 ACK 性能瓶颈在哪？重点查这三项
主库等的是从库的 ACK，而 ACK 触发点是“IO 线程把 binlog 写进 relay log 并 fsync 完”。所以从库的 IO 能力直接决定 ACK 速度。
- 检查从库
sync_relay_log和sync_relay_log_period：必须设为1（每次写都刷盘），否则 ACK 不可靠；但代价是 IO 压力，得配 NVMe SSD - 看从库磁盘写入延迟：
iostat -x 1中%util> 90% 或> 10ms，说明磁盘扛不住 - 确认从库没开
slave_parallel_workers却在重放大事务：SQL 线程卡住 → IO 线程无法推进 → ACK 延迟。此时先关半同步，解决 SQL 线程瓶颈再说
别让半同步和多线程复制互相拖后腿
LOGICAL_CLOCK 多线程复制要求 slave_preserve_commit_order = ON，而这个参数会让从库 SQL 线程刻意排队等前序事务提交完成才发 ACK——相当于把并行优势锁死了。
- 如果用了
slave_parallel_type = LOGICAL_CLOCK，必须同时开slave_preserve_commit_order = ON，这是硬约束 - 但这就意味着：哪怕开了 8 个 worker，ACK 时间仍由最慢的那个事务决定
- 权衡建议：高一致性场景保留该组合；高吞吐场景可切回
slave_parallel_type = DATABASE（需业务分库写入），或直接上 MySQL 8.0 的WRITESET（不依赖 commit order） - 验证是否生效：
SELECT * FROM performance_schema.replication_applier_status_by_worker;查LAST_SEEN_TRANSACTION是否分散，而非全挤在同一个 worker 上
半同步的延迟代价没法彻底消灭，只能收束在可控范围内。最容易被忽略的其实是网络路径——哪怕参数全对，主从走的是同一台交换机下的 VLAN，和跨两跳物理路由器，RTT 差 3 倍，rpl_semi_sync_master_timeout 就得差 3 倍。调参之前，先用 ping 和 mtr 把链路打透。
