双写必须在统一事务边界内执行，典型做法是先写主库再写备库并配补偿机制；一致性校验需分片比对哈希值，注意字段顺序与NULL处理；双写开关须运行时灰度控制并设TTL；切流前需验证反向同步能力。
双写方案里，INSERT 和 UPDATE 必须走同一事务边界
双写不是简单地在应用层发两条 SQL，而是要把新旧库的写操作包进同一个数据库事务（或分布式事务框架），否则必然出现数据不一致。比如用 MySQL 的 XA 事务成本高、兼容性差，更常见的是在应用层用本地事务 + 补偿逻辑。
典型做法是：先写主库（旧库），成功后再写备库（新库）；若第二步失败，必须触发回滚或异步重试，并记录失败日志供人工介入。不能只依赖“写完就算”，因为网络抖动、连接超时、主键冲突都可能让第二条 INSERT 失败而第一条已提交。
- 所有双写路径必须统一收口到一个服务方法，禁止在不同业务模块里各自双写
- 写新库失败时，不能直接抛异常中断用户请求——要降级为单写旧库，并打标
need_sync字段用于后续对账 - 避免在存储过程或触发器里做双写，MySQL 触发器无法跨实例，且会掩盖错误上下文
校验阶段用 CHECKSUM TABLE 只适用于小表，大表必须分块比对
CHECKSUM TABLE 在千万级以上表上会锁表、耗 CPU、拖慢线上查询，生产环境基本不可用。真实迁移中，一致性校验得按业务主键范围切片，逐段比对。
例如按 id 分页：取 SELECT MIN(id), MAX(id) FROM t1，再用 BETWEEN 拆成每 1 万行一段，分别查旧库和新库的 MD5(CONCAT(...)) 或 CRC32 值比对。注意字段顺序、NULL 处理、时间精度（如 DATETIME(3) vs DATETIME(6)）必须完全一致，否则哈希值不同但数据其实一样。
- 校验脚本必须跳过
UPDATE_TIME、CREATE_TIME这类自动生成字段，它们在双写时天然不同 - 使用
SELECT ... INTO OUTFILE导出再比对效率低、磁盘压力大，优先走 JDBC/Connector 直连流式比对 - 校验期间禁止在旧库执行
OPTIMIZE TABLE或ALTER TABLE，会改变ROW_FORMAT导致CHECKSUM失效
双写开关必须支持运行时灰度，不能靠改配置重启生效
上线双写前，得先让一小部分流量（比如按用户 ID 取模）走新库，验证读写链路是否通。这要求开关逻辑嵌入在 DAO 层，而不是靠部署时改 application.yml 再重启服务。
推荐用 Redis 存开关状态：SET write_new_db:order 1 EX 3600，代码里用 redisTemplate.opsForValue().get("write_new_db:" + bizType) 判断。这样可随时关闭某类业务的双写，而不影响其他模块。
- 开关 key 要带业务维度（如
user、order），避免一刀切导致整个系统降级 - 开关失效策略必须设 TTL，防止运维忘记关，长期双写放大延迟和资源消耗
- 任何开关变更都要写入审计日志，包含操作人、时间、影响范围，方便事后追溯
最终切流前，必须跑通「反向同步」兜底能力
切流不是把旧库下线就完事。万一新库出问题（比如慢查询堆积、连接池打满），得能 5 分钟内切回旧库。这就要求反向同步通道始终在线——即新库的变更也要实时写回旧库（哪怕只写关键字段）。
可用 Canal 或 Debezium 捕获新库 binlog，过滤出双写期间的表，再通过轻量级消费者写回旧库。注意反向写入要跳过双写标记字段（如 sync_flag），避免循环同步。
- 反向同步的消费延迟必须监控，超过 10 秒就要告警——它代表故障回切后可能丢失最新数据
- 不要用
mysqldump --single-transaction做兜底备份，它不保证与双写时间点严格一致 - 切流后旧库不能立即停写，至少保留 72 小时只读，等所有双写任务确认完成、反向通道稳定后再下线
JSON_EXTRACT 行为不一致）出错。这些得提前在预发环境用真实流量压测，而不是靠文档拍板。 
