after_sync模式让提交变慢是因为主库需先fsync binlog、再发日志、等待ack、最后才提交事务，增加一次网络等待；但不可关闭，因其确保主库宕机时事务可回滚，避免数据丢失，而after_commit模式下主库先提交再等ack，崩溃会导致已响应客户端的事务未同步而丢失。
为什么AFTER_SYNC模式会让提交变慢但不能关
因为rpl_semi_sync_master_wait_point = AFTER_SYNC要求主库先完成fsync binlog，再发日志、等ACK，最后才调InnoDB提交——这多了一次网络等待，但换来的是主库宕机后事务可安全回滚。如果切到AFTER_COMMIT，主库先提交再发日志，一旦崩溃，客户端已收到成功响应，数据却没同步出去，直接丢事务。
别被“快一点”误导：AFTER_COMMIT不会提升吞吐，只放大丢失风险；且容易和sync_binlog=1、innodb_flush_log_at_trx_commit=1叠加，触发三重刷盘，单事务延迟轻松破10ms。
rpl_semi_sync_master_timeout设多少才算合理
单位是毫秒，不是微秒。默认10000（10秒）在内网太保守——写请求早超时了；设成100又太激进，稍有网络抖动就退化为异步，半同步形同虚设。
- 内网环境建议设为
1000～3000：略高于RTT波动峰，又留出缓冲余量 - 跨机房部署从
5000起，但必须配合监控Rpl_semi_sync_master_no_times是否飙升 - 超时后主库自动降级为异步，但不会自动切回——得靠从库重连触发
slave_parallel_workers > 0却不生效？检查这三个前提
MySQL 5.7的并行复制不是设了线程数就自动跑起来的。常见现象是SHOW SLAVE STATUS\G里Seconds_Behind_Master居高不下，但performance_schema.replication_applier_status_by_worker只显示1个worker在干活。
- 必须执行
STOP SLAVE后再改参数，否则不生效 -
slave_parallel_type必须显式设为'logical_clock'（默认DATABASE在单库场景下完全无效） - 主库
binlog_format必须为ROW，且binlog_transaction_dependency_tracking建议设为WRITESET（8.0+更优，5.7也支持）
哪些“加强可靠性”的配置反而拖垮性能
这些组合看似稳妥，实则是生产中高频踩坑点：
-
rpl_semi_sync_master_wait_for_slave_count = 2：等两个从库ACK，不是高可用，是人为制造延迟瓶颈 - 从库开了
slave_parallel_workers > 0但没配slave_parallel_type = LOGICAL_CLOCK：SQL线程还没执行完，IO线程就发了ACK，主库以为OK，其实数据根本没落地 - 从库
sync_relay_log = 0：relay log只写缓冲区不刷盘，ACK不可靠，主库误判“已接收”，故障时可能丢中继日志
真正影响延迟的，往往不是单个参数，而是参数之间的隐性耦合。比如slave_parallel_workers调再大，若主库组提交频率低（binlog_group_commit_sync_delay设太高），从库照样只能串行追。调参前，先看SHOW PROCESSLIST里从库Slave_IO_Running和Slave_SQL_Running状态，再查磁盘负载，比盲目改timeout有用得多。
