异步复制性能高但数据可靠性低，主库不等待从库确认即提交；半同步复制需至少一个从库写入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 秒）后自动降级为异步。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 实际延迟增加约 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 已成瓶颈，此时半同步形同虚设。