双活迁移不是数据库双主，而是应用层控制的双写+灰度+对账闭环；主从复制天然单向只读，强行写入会破坏链路，且Seconds_Behind_Master=0不保证数据一致，也无法解决schema兼容、跨引擎映射等问题。
双活迁移不是指两个库同时对外提供写服务，而是指在迁移过程中，新老库都保持可写、可读、可校验的状态——但实际写入必须由应用层或中间件严格控制流向。真正能落地的“平滑双活”，本质是「双写 + 流量灰度 + 数据对账」闭环，不是靠数据库自身能力实现的。
为什么不能直接用主从复制做双活？
主从复制天然单向，slave只读，强行写入会破坏复制链路甚至导致数据错乱。Seconds_Behind_Master = 0不等于数据一致：它只表示日志已拉取完，不保证回放完成；大事务、DDL、GTID gap 都可能让从库表面同步实则漏数据。更关键的是，主从无法解决「新老库 schema 不兼容」「跨引擎字段类型映射失败」这类问题。
双写逻辑必须收口到服务层，不能甩给DBA
应用层双写是最可控的方式，但容易踩坑：
- 写失败时的补偿机制缺失：
write_old()成功但write_new()失败，必须有明确的重试队列或本地事务表兜底，不能只打日志 - 自增主键冲突：
auto_increment在两库独立生成，会导致ID重复或跳号；要么停用自增、改用UUID/雪花ID，要么在新库设auto_increment_offset和auto_increment_increment错开 - 时间字段不一致：
NOW()、CURRENT_TIMESTAMP在不同库执行结果可能差几毫秒，校验时要用created_at业务字段而非sysdate() - 事务边界模糊：一个业务操作涉及多张表，双写若没包在同一个分布式事务里（如Seata），极易出现部分写成功、部分失败
校验不是跑一次就完事，得持续+分片+可修复
全量校验耗时太长，10亿行表跑一遍可能要数小时，期间增量还在写。正确做法是：
- 按
id或create_time分段校验，每次只比对1万行，失败记录写入diff_log表 - 校验脚本必须支持「修复模式」：比如发现新库少了一条订单，自动从老库查出完整行，再
INSERT IGNORE补入 - 避开热点时间：校验任务避开凌晨批处理、早高峰写入高峰，否则拖慢主库性能
- 不要只比
COUNT(*)：它掩盖了update覆盖、delete遗漏等静默错误；必须逐字段比对，至少校验主键+业务关键字段（如order_status、pay_amount）
切流不是改个连接串，而是三件事必须原子执行
切读流量时，常见故障是旧连接未断、中间件路由未更新、缓存未穿透，导致新库查不到刚写入的数据：
- 先停写老库：
SET GLOBAL read_only = ON，并立刻SELECT @@read_only确认生效；别用FLUSH TABLES WITH READ LOCK，它会阻塞所有DML - 清空应用连接池：Spring Boot用
DataSource.getConnection().close()触发销毁，或调用HikariCP的evictAllConnections() - 中间件同步更新：如果用了
ShardingSphere或MyCat，必须在切流前发布新路由规则，并验证show status like 'shard%'是否生效
最易被忽略的是缓存一致性：切流后老库不再写入，但Redis里还存着旧库读出来的脏数据，必须配合cache-aside策略，在写新库同时主动DEL对应key，而不是等TTL过期。
