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