双主架构下仅靠auto_increment_offset和auto_increment_increment配置无法彻底解决数据冲突，因为它仅避免insert主键重复，不防范update/delete并发覆盖、业务逻辑冲突及应用层写同一行导致的数据不一致。
双主架构下仅靠 auto_increment_offset 和 auto_increment_increment 配置，无法彻底解决数据冲突，它只防 INSERT 主键碰撞，不防 UPDATE/DELETE 冲突、不防业务逻辑覆盖、不防应用层并发写同一行。
为什么自增步长配置只能解决一半问题
该配置本质是让两台主库生成的自增 ID 互斥：比如主库 A 设为 offset=1, increment=2 → 生成 1/3/5…；主库 B 设为 offset=2, increment=2 → 生成 2/4/6…。这样 INSERT 不会因主键重复中断复制。
但它完全不管以下场景：
-
UPDATE users SET balance = balance + 100 WHERE id = 123：两端同时执行，结果取决于谁后 apply，最终值错误 DELETE FROM logs WHERE created_at ：两边都删，可能多删或漏删（尤其跨时区）- 应用先
SELECT再UPDATE，但中间另一端已改过该行，导致覆盖而非合并
也就是说，auto_increment 配置只是“让复制不崩”，不是“让数据一致”。
必须同步调整的三项关键配置
光调 offset/increment 不够，漏掉任一配置，批量插入、并发写、binlog 解析都会出乱子：
- 两台主库都必须设
innodb_autoinc_lock_mode = 0（传统锁模式），否则INSERT ... SELECT或LOAD DATA可能跳号、错号，导致后续 INSERT 碰撞 - 必须开启
log_slave_updates = ON，否则 relay log 中的变更不会记入本机 binlog，双向复制断裂，且无法支持 GTID 或工具校验 - 必须确保
server-id全局唯一（如 A=1，B=2），MySQL 靠它过滤回环——否则 A→B→A 的变更会被重复执行
比配置更关键的是写入控制策略
真正决定双主是否可用的，不是参数，而是谁在什么时候往哪台库写什么数据：
- 禁止应用直连双主做“自动负载均衡”写入，这等于主动制造冲突
- 按业务拆分写入：例如
user表全走主库 A，order表全走主库 B；或按user_id % 2路由，奇数 ID 写 A，偶数写 B - 所有 UPDATE/DELETE 改为幂等操作：加
WHERE version = ?或AND updated_at = ?，失败则重试或告警，不盲目覆盖 - 删除操作统一转为
UPDATE ... SET is_deleted = 1，物理删除交给单点异步任务
这些策略无法用 SQL 命令一键启用，得改应用路由逻辑或加中间件规则。
冲突发生后，别信“自动修复”
一旦出现数据不一致，pt-table-sync 这类工具只能在无写入窗口期临时救急，且它默认按“后写入覆盖”处理，可能丢数据：
- 它不理解业务语义（比如“余额增加”不能简单用时间戳判先后）
- 修复过程本身要锁表或阻塞写入，线上慎用
- 若复制已中断多时，
pt-table-checksum校验可能误报或漏报
真正可靠的方案，是把冲突概率压到趋近于零——靠分区写入 + 自增隔离 + 应用幂等，而不是靠事后补救。
