异步复制性能高但数据可靠性低，主库不等待从库确认即提交；半同步复制需至少一个从库写入relay log并返回ACK后才提交，牺牲少量性能换取RPO≈0的数据安全性。
没有“更好”，只有“更合适”——异步复制和半同步复制不是性能高低之争，而是数据可靠性与写入延迟之间的权衡取舍。
异步复制为什么快？关键在“不等”
主库执行 INSERT 或 UPDATE 后，只要写完本地 binlog 并提交事务，立刻返回客户端，完全不关心从库是否收到、是否写入 relay log。IO 线程在后台慢慢拉日志，SQL 线程再慢慢回放。
- 典型延迟：主从之间可能积压几秒甚至几分钟（尤其大事务或从库负载高时）
- 故障风险：
mysqld崩溃瞬间未发送的binlog永久丢失，切换后数据不一致 - 适用场景：
read_only=OFF的分析型从库、跨机房灾备、日志归档库 - 性能代价几乎为零：TPS 接近单机极限，
sync_binlog=1和innodb_flush_log_at_trx_commit=1才会影响写入吞吐
半同步复制慢在哪？慢在“等一个 ACK”
主库必须等至少一个从库返回 ACK（确认已接收并写入 relay log 文件），才提交事务并响应客户端。这个等待过程是串行阻塞的，超时（默认 10 秒）后自动降级为异步。
- 实际延迟增加约 5–20ms（取决于网络 RTT 和从库 I/O 能力）
- 但数据安全边界明确：
rpl_semi_sync_master_enabled=ON且AFTER_SYNC模式下（MySQL 5.7+ 默认），主库崩溃后，已 ACK 的事务一定存在于某个从库的relay log中 - 容易踩的坑：
- 从库未开启
rpl_semi_sync_slave_enabled=1，主库会静默退化为异步（SHOW STATUS LIKE 'Rpl_semi_sync_master_status'显示OFF） -
max_allowed_packet主从不一致，导致握手失败，半同步插件加载成功但实际不生效 - 从库启用并行复制（
slave_parallel_workers > 0）时，ACK可能滞后于事务写入顺序，影响一致性语义
- 从库未开启
怎么判断该用哪个？看你的 RPO 和可用性底线
RPO（Recovery Point Objective）是你能容忍的最大数据丢失量。如果 RPO = 0（即“一比特都不能丢”），异步复制直接出局；如果 RPO ≤ 1 秒，半同步是现实可行的底线。
- 电商订单、用户账户变更、支付流水：必须用半同步，哪怕 TPS 下降 15%，也比补单/对账强
- 用户行为日志、监控指标、离线报表：异步足够，加个
slave_parallel_type=LOGICAL_CLOCK和slave_parallel_workers=4就能扛住延迟 - 别迷信“全同步”：MySQL 原生不提供真正全同步（所有从库 fsync 完毕才提交），
Group Replication是另一套机制，运维复杂度和延迟远超半同步 - 真实生产中，常混合部署：核心业务库用半同步 +
read_only=ON从库；报表库用异步 + 单独 binlog server 中转
最常被忽略的一点：半同步不是开个插件就万事大吉。你得定期检查 Rpl_semi_sync_master_clients 是否 ≥ 1，监控 Rpl_semi_sync_master_no_times 是否持续增长——后者意味着频繁超时降级，说明网络或从库 I/O 已成瓶颈，此时半同步形同虚设。
