MySQL双主复制不自动解决冲突，必须依赖写入分离、错开自增ID、禁用双向UPDATE/DELETE及强化监控等人工规避手段；GTID仅提升冲突定位精度，无法消除业务层写冲突。
MySQL 8.0 双向复制（双主）本身不支持自动冲突解决，GTID 不能消除写冲突，只能让冲突暴露得更快、定位更准；真正避免冲突必须靠应用层或中间件做写路由，一致性哈希只是其中一种策略，不是 MySQL 内置功能。
为什么 GTID 无法解决双向复制的冲突
GTID 的作用是唯一标识事务、简化位点管理、防止重复执行，但它不参与冲突检测或仲裁。在双主配置下：
- 两台服务器都启用
gtid_mode=ON和enforce_gtid_consistency=ON，但各自生成的 GTID 中source_uuid不同 - 当 Server A 和 Server B 同时对同一行（如
user_id=1001）执行UPDATE balance = balance + 100，两个事务都会成功提交，并各自生成一个 GTID - 复制线程把对方的事务拉过来后，SQL 线程照常执行——结果取决于谁先执行、谁后覆盖，不是“合并”，而是“覆盖”
- 一旦发生主键/唯一键冲突（如双主同时插入
id=5），从库 SQL 线程直接报错ERROR 1062 (23000): Duplicate entry '5' for key 'PRIMARY'，复制中断
auto_increment_offset + increment 只能防 ID 冲突，不能防业务逻辑冲突
这是最常被误用的“防冲突方案”。它只解决自增主键重复问题，对以下场景完全无效：
- 更新同一张表的同一行记录（
UPDATE t SET status='paid' WHERE order_id='ORD-001'） - 插入带业务唯一约束的字段（如
email、phone、order_no） - 删除操作顺序敏感（A 删了某行，B 同时对该行做更新）
示例配置看似安全，实则脆弱：
Server A: server-id = 1 auto_increment_increment = 2 auto_increment_offset = 1 # → 生成 1,3,5,7... <p>Server B: server-id = 2 auto_increment_increment = 2 auto_increment_offset = 2 # → 生成 2,4,6,8...
但只要应用没做写隔离，INSERT INTO users (email) VALUES ('a@b.com') 在 A 和 B 上同时执行，依然会触发唯一键冲突。
一致性哈希必须由客户端或 Proxy 实现，MySQL 不感知
MySQL 8.0 本身没有哈希路由能力。所谓“一致性哈希策略”，是指在接入层将写请求按某个字段（如 user_id、tenant_id）哈希后固定打到某台主库，确保同一业务实体的所有写操作始终落在同一节点：
- 哈希函数示例：
hash(user_id) % 2 == 0 → 写 Server A；否则写 Server B - 需保证哈希算法稳定（不随节点增减剧烈重分布），推荐使用
ketama或rendezvous算法 - Proxy 方案可选
MySQL Router（配合 InnoDB Cluster）、ProxySQL（支持 query rule + hash）、或自研网关 - 客户端直连时，必须在业务代码中实现哈希逻辑，且要处理节点故障后的 failover 路由切换
关键点：一旦哈希路由失效（比如缓存了错误的节点映射、网络分区导致心跳误判），双写立刻回归原始冲突风险。
真正可控的替代方案：单主 + 多副本 + Proxy 自动切主
MySQL 8.0 官方明确建议生产环境用单主模式，而非双主。MGR（组复制）或传统主从 + Proxy（如 HAProxy + Orchestrator）才是稳妥路径：
- MGR 单主模式下，只有 Primary 节点接受写入，其他节点自动降为只读，从源头杜绝写冲突
- Primary 故障时，MGR 内部通过 Paxos 投票选出新 Primary，GTID 确保切换后复制位置自动对齐
- Proxy 层监听 MGR 状态（查
performance_schema.replication_group_members），实时更新写入口地址 - 若坚持需要“多点写入”，应改用分片架构（sharding），每个分片内仍是单主，跨分片事务由应用或分布式事务中间件（如 Seata）协调
容易被忽略的是：mysql.gtid_executed 表虽可用于比对各节点已执行 GTID 集合，但它只告诉你“谁漏了什么”，不帮你修复——修复仍需人工干预或外部校验工具（如 pt-table-checksum）。
