自增步长配置仅规避insert主键碰撞，无法解决update/delete并发覆盖、select-update竞态及跨库写同一行等事务冲突，因其不参与锁机制、mvcc或事务隔离控制。
单纯调大 auto_increment_increment 不能缓解事务冲突，它只影响 INSERT 主键生成逻辑，对 UPDATE/DELETE 并发覆盖、SELECT-UPDATE 竞态、跨库写同一行等真实冲突场景完全无效。
为什么自增步长和事务冲突是两回事
auto_increment_increment 和 auto_increment_offset 只决定新插入记录的主键值怎么算，不参与任何锁机制、事务隔离或并发控制。事务冲突的核心是：多事务同时读写同一行数据时，MVCC 或锁策略无法协调最终状态。
- INSERT 冲突（主键重复）确实能被 offset/increment 规避，但这只是复制层“不断掉”的底线，不是事务一致性的保障
- UPDATE users SET balance = balance + 100 WHERE id = 123；两端同时执行 → 最终 balance 只加了一次，而不是两次
- 应用 SELECT id, version FROM orders WHERE order_no = 'A'，再 UPDATE ... WHERE id = ? AND version = ?；若中间另一端已更新 version，当前 UPDATE 就会失效 —— 这和自增步长无关
真正影响事务冲突的三个关键配置
如果你在双主或高并发写入场景下遇到事务级不一致，优先检查以下三项，它们比自增参数更直接关联事务行为：
- 必须设
innodb_autoinc_lock_mode = 0：否则INSERT ... SELECT或批量导入可能跳号，导致后续 INSERT 因主键错位而失败或覆盖 - 必须开
log_slave_updates = ON：否则本机 relay log 不记 binlog，双向复制链断裂，GTID 失效，且 pt-table-checksum 等校验工具无法工作 - 必须确保
server-id全局唯一（如 A=1, B=2）：MySQL 靠它识别并丢弃回环事件（A→B→A），否则同一条变更会被反复 apply
应用层该做什么，而不是依赖数据库自增
自增步长是被动防御，事务冲突需要主动治理。重点不在 SQL 参数，而在写入路径设计：
- 禁止应用直连双主做“自动负载均衡”——这是冲突高发源头，应由中间件或路由规则强制分库分表
- UPDATE/DELETE 必须带校验条件：
UPDATE t SET status = 'done' WHERE id = 123 AND status = 'pending'，失败即重试或告警 - 物理删除统一转为软删：
UPDATE logs SET is_deleted = 1 WHERE ...，后续单点异步清理，避免双删语义不一致 - 所有跨库写操作必须有幂等 key（如
order_no+event_id），配合唯一索引拦截重复
自增步长配置容易让人误以为“设了就安全了”，但实际它只解决最表层的 INSERT 主键碰撞。真正的事务冲突治理，得从写入路由、SQL 条件、应用重试逻辑和删除语义四个层面同步动手——漏掉任一环节，光调 auto_increment_increment 就只是给定时炸弹换个外壳。
