MySQL 半同步复制主要有两种实现方式，其核心区别在于主库何时回复客户端事务提交成功（即何时认为事务完成），这直接影响了数据安全性和性能。这两种方式由参数 rpl_semi_sync_master_wait_point 控制（在 MySQL 5.7 及以后版本中，推荐使用 AFTER_SYNC）：

AFTER_COMMIT (MySQL 5.6 / 5.7 早期默认，现已不推荐)
AFTER_SYNC (MySQL 5.7 及以后推荐配置，MySQL 8.0 默认)

深入分析与利弊对比

特性	`AFTER_COMMIT`	`AFTER_SYNC` (推荐)
等待点	主库事务提交后等待ACK	主库事务写入Binlog后、提交前等待ACK
控制参数	`rpl_semi_sync_master_wait_point = AFTER_COMMIT`	`rpl_semi_sync_master_wait_point = AFTER_SYNC`
数据安全性	较低 (存在数据丢失风险)	较高 (强一致性保障)
数据一致性	主库可见数据 != 从库已接收数据	主库可见数据 == 从库已接收数据
故障切换风险	高 (可能导致数据丢失)	低 (保障故障切换数据一致)
性能	相对稍好	相对稍差 (但差距通常很小)
客户端感知延迟	提交后等待ACK，延迟较大	写入Binlog后等待ACK，提交在ACK后，延迟稍小
推荐版本	MySQL 5.6 / 5.7 早期	MySQL 5.7+ (强烈推荐), MySQL 8.0 (默认)

1. `AFTER_COMMIT` (不推荐)

工作流程：
1. 客户端发起 COMMIT。
2. 主库在存储引擎内部提交事务，使事务对主库上的其他会话可见。
3. 主库将事务的 Binlog 发送给从库。
4. 主库等待至少一个启用了半同步复制的从库返回 ACK 确认（表示该从库已接收并写入其自己的 Relay Log）。
5. 主库收到 ACK 后，回复客户端 COMMIT 成功。
6. 从库的 SQL 线程异步应用 Relay Log 中的事务。
优点:
- 相对于 AFTER_SYNC，在等待 ACK 期间主库上的锁（如 InnoDB 行锁）可能释放得更早（因为事务已在主库提交），理论上在高并发、锁竞争激烈的场景下对主库的吞吐量有轻微优势（但实际差距通常很小）。
缺点 (重大风险 - 主要不推荐的原因):
- 数据丢失风险: 这是最核心的问题。如果在主库提交后（步骤2）、但在收到从库 ACK 之前（步骤4-5之间）主库发生崩溃且无法恢复，那么：
  - 主库上该事务已提交，对客户端来说是成功的。
  - 客户端认为数据已安全存储。
  - 但该事务的 Binlog 可能尚未发送到从库，或者从库接收到了但尚未写入 Relay Log 并返回 ACK。
  - 当故障切换到新的主库（原从库）时，这个“已提交”的事务会丢失！因为它在新主库上不存在。这违反了用户对“半同步”保障数据安全的预期。
- 数据不一致窗口: 在主库提交后（客户端可见数据）、到从库确认并应用事务之前，主库和从库的数据是不一致的。其他在主库上读取到该数据的会话，如果查询从库，会看到旧数据。
- 客户端感知延迟: 客户端需要等待主库提交加网络往返（等待 ACK）的时间，感知到的提交延迟较长。

2. `AFTER_SYNC` (强烈推荐，MySQL 8.0 默认)

工作流程：
1. 客户端发起 COMMIT。
2. 主库将事务写入 Binlog 文件（通常是 fsync 到磁盘）。
3. 主库将事务的 Binlog 发送给从库。
4. 主库等待至少一个启用了半同步复制的从库返回 ACK 确认（表示该从库已接收并写入其自己的 Relay Log）。
5. 主库收到 ACK 后，在存储引擎内部提交事务，使事务对主库上的其他会话可见。
6. 主库回复客户端 COMMIT 成功。
7. 从库的 SQL 线程异步应用 Relay Log 中的事务。
优点:
- 强数据安全保证 (核心优势): 这是推荐 AFTER_SYNC 的根本原因。只有在确保事务 Binlog 至少已安全传递到一个从库（写入其 Relay Log）后，主库才提交事务并对客户端报告成功。因此：
  - 如果主库在回复客户端成功之前崩溃，事务在主库上未提交（虽然 Binlog 已写入），客户端知道失败。
  - 如果主库在回复客户端成功之后崩溃（即已提交），那么该事务的 Binlog 必定已存在于至少一个从库的 Relay Log 中。故障切换到该从库后，这个事务一定能被新主库应用，不会丢失。这满足了半同步复制防止数据丢失的设计目标。
- 数据一致性窗口更小: 一旦主库提交（步骤5），数据在主库可见，此时确认该数据已存在于至少一个从库的持久化存储（Relay Log）中。虽然从库可能还未应用，但数据已安全抵达。其他会话在主库读到数据后，即使立即查从库看到旧数据，也知道这是因为复制延迟（异步应用），而不是数据丢失风险。
- 客户端感知延迟稍低: 客户端等待的时间是 Binlog 写入（通常很快） + 网络往返（等待 ACK）的时间。主库自身的提交操作（步骤5）是在后台完成的，不阻塞客户端响应（虽然客户端已收到成功响应，但其他会话看到数据可能还有极短暂延迟）。
缺点:
- 锁持有时间稍长: 在等待 ACK 期间（步骤4），事务在主库的存储引擎层尚未提交，因此它持有的锁（如 InnoDB 行锁）不会被释放。这可能在极高并发、锁竞争非常激烈的场景下，对主库的吞吐量造成极其轻微的影响（但现代硬件和网络下，这种影响通常可以忽略不计，远小于数据安全的收益）。这就是所谓的“无损半同步”的代价（保障数据无损）。
- 对网络延迟更敏感: 等待 ACK 发生在提交之前，网络延迟会直接影响事务提交的整体延迟和吞吐量。需要确保网络质量良好。

总结与强烈建议

AFTER_COMMIT 应避免使用： 其设计缺陷（主库提交后等待 ACK）导致在主库崩溃时存在已提交事务丢失的风险，这违背了使用半同步复制提高数据安全性的初衷。MySQL 社区和官方早已认识到此问题。
AFTER_SYNC 是当前的最佳实践和标准配置：
- 它真正实现了半同步复制防止数据丢失的核心价值：确保每个对客户端报告成功提交的事务，其 Binlog 必定已持久化在至少一个从库上。
- 它提供了更强的数据一致性和故障切换安全性。
- 其潜在的性能开销（锁持有时间稍长）在绝大多数生产环境中微乎其微，且是保障数据安全必须付出的合理代价。
- MySQL 8.0 已默认使用 AFTER_SYNC，这充分说明了其重要性。

最佳实践

始终配置 rpl_semi_sync_master_wait_point = AFTER_SYNC (MySQL 5.7+) 或直接使用 MySQL 8.0 (默认即为 AFTER_SYNC)。
确保至少有一个稳定且低延迟的从库启用了半同步复制 (rpl_semi_sync_slave_enabled = ON)。
合理设置 rpl_semi_sync_master_timeout (等待 ACK 的超时时间)。太短容易退化为异步，太长在主库故障时影响可用性。需要根据网络情况和业务容忍度权衡。
监控半同步状态：检查 Rpl_semi_sync_master_status (主库是否启用了半同步)，Rpl_semi_sync_master_clients (连接的半同步从库数量)，Rpl_semi_sync_master_yes_tx / Rpl_semi_sync_master_no_tx (成功/失败通过半同步提交的事务数) 等状态变量。
理解半同步只能保证 Binlog Event 传输到从库 Relay Log 的持久化，并不保证从库 SQL 线程已应用。要保证读从库的强一致性，需要结合其他机制（如 MySQL Group Replication, InnoDB Cluster, 或外部一致性读方案）。
对于极致性能要求且可容忍少量数据丢失的场景，纯异步复制仍是选项。对于零数据丢失要求，需要结合 AFTER_SYNC 和更高级别的 HA 方案（如 MGR 或同步复制集群）。