在 MySQL 中，复制模式的选择对性能和数据一致性有重要影响。正确配置复制方式可以在保证数据安全的同时提升系统吞吐量和响应速度。MySQL 提供了三种主要的复制模式：异步复制（Async）、半同步复制（Semi-Sync）和组复制（Group Replication）。选择合适的模式需结合业务场景、延迟容忍度和数据一致性要求。
异步复制：最高性能，最低一致性保障
异步复制是 MySQL 默认的复制方式。主库执行事务后立即返回结果给客户端，不等待从库确认是否接收或应用日志。
优点： 主库性能最好，写入延迟最小 适用于高并发写入、对延迟敏感的场景 缺点： 存在数据丢失风险，主库崩溃时未同步的数据无法恢复 从库可能滞后严重，导致读一致性问题适合用于数据分析、报表类系统等可以容忍短暂数据不一致的场景。
半同步复制：平衡性能与数据安全
半同步复制要求主库在提交事务前，至少有一个从库确认接收到并写入中继日志。通过插件
semisync_master启用。 优点： 避免主库宕机导致的数据丢失 性能比异步略低，但多数情况下可接受 建议配置： 设置
rpl_semi_sync_master_wait_for_slave_count = 1，避免等待多个从库拖慢性能 启用
rpl_semi_sync_master_timeout防止主库无限等待，超时后自动退化为异步
推荐用于核心业务系统，如订单、支付等需要一定数据可靠性的服务。
组复制（Group Replication）：强一致性，高可用
基于 Paxos 协议实现多节点数据同步，支持单主或多主模式，确保事务在多数节点达成共识后才提交。
优点： 自动故障切换，数据强一致 支持多写入点（多主模式） 缺点： 网络延迟敏感，跨机房部署性能下降明显 配置复杂，资源消耗较高适用于对高可用和数据一致性要求极高的系统，如金融交易系统。但在高写入负载下可能出现性能瓶颈。
优化建议与实际选择策略
根据实际需求权衡性能与可靠性：
纯读多写少场景可使用异步复制 + 多从库分担查询压力 关键业务推荐启用半同步复制，并搭配一个低延迟的本地从库 避免所有从库都开启半同步，可部分节点异步用于备份或分析 监控复制延迟（Seconds_Behind_Master），及时发现网络或IO瓶颈 合理设置
sync_binlog和
innodb_flush_log_at_trx_commit配合复制模式使用
基本上就这些。关键是根据你的应用对数据安全和性能的要求做取舍，没有“最好”的模式，只有“最合适”的方案。
