零停机割接需分阶段实施：双写兜底（DAO层拦截、主键一致、禁DDL）、增量追平（ROW格式binlog、手动position衔接）、灰度切读（哈希分片、缓存隔离、fallback机制），辅以抽样checksum校验和72小时新库监控。
能做，但必须放弃“一次切完”的幻想。零停机割接不是技术魔术，而是靠分阶段控制写入路径、校验节奏和回滚能力换来的——核心就三点：双写兜底、增量追平、灰度切读。
双写必须在应用层拦截，不能依赖中间件或代理
很多团队想用 ShardingSphere 或 MyCat 做自动双写，结果发现它们对事务边界、异常分支、主键生成逻辑支持极弱，一出错就丢数据。真正可控的双写，得落在 DAO 层或 ORM 插件里。
-
MyBatis场景下，用Interceptor拦截update/insert/delete方法，在同一个本地事务里向新旧库各发一次 SQL； - 必须确保新库写入失败时，整个事务回滚（旧库也 rollback），否则会出现“旧库有、新库无”的单边写；
- 主键必须一致：
AUTO_INCREMENT表要提前在新库设好auto_increment_offset和auto_increment_increment，避免双写冲突； - 禁止在双写期间修改表结构——DDL 会中断 binlog 流，导致后续增量同步断链。
增量同步必须基于 ROW 格式 binlog，且跳过 DDL 事件
用 canal 或 Debezium 同步时，如果源库 binlog_format 不是 ROW，就会漏掉 UPDATE 的字段级变更，校验永远不通过。更隐蔽的坑是 DDL 事件本身：目标库表结构已由全量导入固定，再执行一遍 ALTER TABLE 可能直接报错中断。
- 确认源库配置：
binlog_format = ROW、binlog_row_image = FULL； -
canal配置中显式关闭 DDL 解析：canal.instance.filter.regex = .*\..*（只过滤库表名），再加canal.instance.filter.black.regex = .*\..*排除 DDL； - 监控
canal的delay指标，超过 5 秒就要告警——延迟高往往意味着目标库写入瓶颈或主键冲突； - 别信“全量+增量自动衔接”：全量导出时刻的
binlog position必须手动记下，增量任务必须从该 position 启动，否则中间有 gap。
灰度切读必须按用户 ID 或订单号分片，不能按时间切
电商场景下，“昨天的数据读新库、今天的数据读旧库”这种时间切法完全不可行——一个用户可能跨天下单，订单详情页要关联用户信息、地址、商品，多表 join 跨库根本没法做。唯一可行的是按业务主键哈希分片，让同一实体的所有读请求始终落在同一侧。
- 用
user_id % 100或order_no.substring(0,4) % 100生成分片键，前期只放通 1% 流量（比如 hash 值为 0 的用户）； - 读接口加日志埋点：记录每次查询走的是旧库还是新库、耗时、是否命中缓存、返回数据是否与旧库比对一致；
- 缓存 key 必须带库标识，例如
user:12345:old和user:12345:new分开存，避免切读后缓存污染； - 一旦发现新库查不到数据（比如冷数据未完成全量迁移），立刻 fallback 到旧库，并打标
miss_new上报，用于驱动补迁任务。
校验不能只看行数，必须做抽样 checksum 对比
亿级表总行数一致，只说明没大面积丢数据，但可能每万行里错 1 行——这种错误在报表、对账、风控场景里就是事故。真正的校验得落到数据内容上，而且得快，不能拖慢上线节奏。
- 用
pt-table-checksum或自研脚本，按主键范围分块（如id BETWEEN 1000000 AND 2000000），每块计算CRC32(CONCAT(...))； - 只校验核心字段：主键、状态字段、金额、时间戳，跳过大文本和 JSON 字段（容易因空格/换行差异误报）；
- 校验频率：全量完成后跑一次；双写开启后每小时跑一次热点分片；切读前 2 小时内再跑一次全部分片；
- 发现不一致时，优先查 binlog 日志确认是哪条变更没同步过去，而不是直接覆盖重写——覆盖可能掩盖上游业务逻辑 bug。
最易被忽略的一点：切写流量不是“开关一拨就完事”，而是要持续观察至少 72 小时的新库慢 SQL、连接池打满、主从延迟飙升等信号。很多团队在第 36 小时看到一切正常就下线旧库，结果第 48 小时遇到一个未复现的分布式事务超时，才意识到新库的事务隔离级别设置错了。
