dual write不是开箱即用功能，而是需手动设计、事务兜底、灰度控制、异步补偿并全程监控的写入策略；它必须统一收口、禁止跨库裸sql、开关动态可配、校验分片哈希、反向同步必验。
dual write 本身不是开箱即用的“功能”，而是一套必须手动设计、严格约束、全程监控的写入策略。它不能靠加个开关就生效，更不能靠“多发一条 SQL”来凑数——一旦漏掉事务边界、补偿逻辑或灰度控制，数据不一致就是分分钟的事。
双写必须包在同一个本地事务里，不能只靠应用层发两条 SQL
常见错误是：先 oldDB.insert()，再 newDB.insert()，中间没事务兜底。哪怕两个库都用了 @Transactional，也只各自保证单库原子性，无法防止“旧库成功、新库失败”的中间态。
正确做法是：所有双写入口统一收口到一个服务方法，且该方法内只开启一次本地事务（比如 Spring 的 @Transactional），并在其中完成两库写入；若新库写失败，整个事务回滚旧库操作——但这要求旧库支持回滚（比如不能是只读库或已提交不可逆状态）。
更现实的折中方案是：旧库写成功后，异步触发新库写入，并立即记录一条 sync_task 到本地事务表；失败时靠定时任务捞取未完成任务重试，同时打标 need_sync=1 字段供后续对账修复。
- 禁止在 MySQL 存储过程或触发器里做双写——跨实例不支持，且错误堆栈难定位
- INSERT 和 UPDATE 必须走同一套双写路径，避免部分操作漏进新库
- DELETE 操作尤其危险，建议先软删（
is_deleted=1），等校验稳定后再物理清理
双写开关必须运行时可调、带业务维度、有 TTL
上线前不灰度 = 把全量流量当测试用例。硬编码开关、改配置重启、全局开关一刀切，都是线上事故高发区。
推荐用 Redis 存开关状态：SET write_new_db:order 1 EX 3600，代码里通过 redisTemplate.opsForValue().get("write_new_db:" + bizType) 动态判断。这样既能按用户 ID、订单类型等维度灰度，又能防运维忘记关闭导致长期双写放大延迟。
- 开关 key 必须带业务标识（如
user、payment），避免订单双写正常但用户资料还在单写 - TTL 不建议超过 24 小时，超时自动失效，强制人工确认是否继续
- 开关变更要配套日志埋点，比如 “
write_new_db:order从 0 → 1，operator=admin”
校验不能依赖 CHECKSUM TABLE，大表必须分片比对哈希
CHECKSUM TABLE t1 在千万级以上表上会锁表、拖慢查询、吃光 CPU，生产环境基本不可用。真实迁移中，一致性校验得按主键范围切片，逐段比对。
例如：查出 SELECT MIN(id), MAX(id) FROM t1，再用 BETWEEN 拆成每 1 万行一段，分别在新旧库执行：
SELECT MD5(CONCAT_WS('|', id, name, status, updated_at)) FROM t1 WHERE id BETWEEN 10000 AND 20000;
注意字段顺序、NULL 处理（CONCAT_WS 会跳过 NULL）、时间精度（DATETIME(3) vs DATETIME(6)）必须完全一致，否则哈希值不同但数据其实一样。
- 禁止用导出 SQL 再比对——磁盘 IO 压力大、临时文件易满、无法流式处理
- 校验期间禁止在旧库执行
ALTER TABLE，会改变ROW_FORMAT导致哈希失效 - 校验任务应避开业务高峰，且每次只拉少量数据（比如 1000 行）做流式比对
切流前必须验证反向同步能力，不能只测正向
很多人只验证“旧库写 → 新库同步”，却忽略“新库写 → 旧库同步”这个反向链路。一旦切写后发现某些字段（如 updated_by、sync_version）在新库被更新，但旧库没收到，就会导致后续双写逻辑错乱甚至覆盖。
典型场景：用户修改地址，新库更新了 address 和 updated_at，但旧库仍保留老值；之后又发生一笔双写，旧库把老 address 写回新库，直接覆盖刚才的修改。
- 反向同步需提前接入 Canal 或 Flink-CDC，并在双写阶段就开启监听
- 切流前跑一次“模拟写入+反向校验”压测，确保关键字段能闭环
- 所有自动生成字段（如
create_time、row_id）必须在双写时显式赋值或忽略比对，不能依赖数据库默认行为
