主从复制仅主库可写，双主复制两端均可写但需自行处理冲突；主从适用于读多写少、强一致性场景，双主适用于跨机房、最终一致性场景，但存在循环复制、ID冲突、延迟不可见等风险，运维复杂度远高于主从。
主从复制只能写主库，双主复制两边都能写
这是最根本的差异：主从架构下，INSERT/UPDATE/DELETE 必须发给唯一 master，从库（slave）设为只读（read_only=ON），强行写会报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。而双主是两个节点互为 master 和 slave，应用可向任意一端发起写请求——但这也意味着你必须自己兜底解决冲突。
- 主从适合读多写少、强一致性要求高的场景（如订单中心），写路由集中，运维简单
- 双主适合跨机房部署、需就近写入、且能接受最终一致性的业务（如日志采集、用户行为埋点）
- 双主必须配
auto_increment_increment和auto_increment_offset，否则自增 ID 必撞（比如 A 设offset=1, increment=2→ 用奇数；B 设offset=2, increment=2→ 用偶数）
双主复制天然存在循环写入和数据覆盖风险
假设 M1 和 M2 是双主，M1 执行 UPDATE t SET balance = 150 WHERE id = 1，binlog 同步到 M2 并执行；M2 紧接着也执行了 UPDATE t SET balance = 130 WHERE id = 1，再同步回 M1 —— 最终结果取决于谁后写、谁后同步，不是“谁先提交谁生效”。更危险的是，若没关掉 log_slave_updates 或没设对 server-id，一条语句可能在双主间无限循环复制（M1→M2→M1→M2…）。
- 必须确保
server-id全局唯一，且双主都开启log_slave_updates=ON（否则无法接力同步） - 推荐使用
binlog_format=ROW，避免STATEMENT格式下函数（如NOW()、UUID()）在两端产生不同结果 - 禁止在双主上执行非确定性语句（如不带
WHERE的UPDATE、DELETE），否则极易导致数据不一致
主从延迟是常态，双主“伪实时”但更难观测
主从延迟（Seconds_Behind_Master）可直接查 SHOW SLAVE STATUS，几秒到几分钟都常见；而双主没有这个指标——你看到 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes，不代表数据已对齐。因为 M1 写完立刻返回成功，M2 可能还在重放中，此时若切流量过去，就可能读到旧值或空数据。
- 主从可用
pt-heartbeat或写入时间戳表来监控真实延迟 - 双主建议加应用层校验：关键写操作后，主动查另一端确认（例如插入后立即按主键查一次对方库）
- 不要依赖
SELECT ... FOR UPDATE跨双主加锁，它只锁本机，另一端完全不受影响
双主不是高可用银弹，故障切换反而更复杂
很多人以为“双主=自动 failover”，其实恰恰相反：当 M1 宕机，所有写自动切到 M2，看似无缝；但 M1 恢复后，若未及时修复复制链路，M2 新增的数据不会反向同步回 M1，M1 成为脏数据源。更糟的是，如果应用在 M1 宕机期间仍往它发请求（比如 DNS 缓存未刷新），会产生写失败或连接超时，而这些失败请求若没做幂等重试，就会丢数据。
- 双主必须配合中间件（如 ProxySQL、MaxScale）或应用层路由策略，不能裸连
- 务必禁用
skip-slave-start，并配置slave_net_timeout和master-retry-count防断连雪崩 - 真正需要高可用，优先考虑 MHA、Orchestrator 或 MySQL Group Replication，而不是硬上双主
