国产数据库迁移的数据一致性，核心是让迁移前后的同一笔业务在库里的结果对得上：行数、主键、金额、时间戳、状态字段、关联关系都要一致，并且切换期间业务不能出现重复入账或漏单。做法上不外乎三条路径——停机一次性迁移、双写并行过渡、按模块分批迁移。选哪条，取决于业务能停多久、存量数据有多大、上下游系统有多少。
这里讨论的是通用工程做法，不针对某一款数据库。更多技术实现细节中有一批方法论性的记录，可以配合阅读。
方案一：停机窗口内一次性迁移
这是最直白的方式。在业务低峰期停止写入，用数据库自带的导出导入工具或第三方迁移工具把存量数据全量搬过去，比对通过后切换应用连接串，再开放写入。整个过程的难点是可停时长能否覆盖全量搬迁加校验。
它的优缺点都很清楚：
- 优点：逻辑最简单，不存在迁移期间新旧库同时被写的状态，一致性主要靠迁移前后的一次比对保证。
- 优点：回退容易。切换失败就改回原连接串，只要迁移期间没开放写入，原库数据没被动过。
- 缺点：对业务连续性有影响，停机窗口越长压力越大，长窗口往往只能安排在节假日。
- 缺点：全量迁移的耗时随数据量增长，窗口不好估算，容易留不足校验时间。
- 缺点：切换那一刻的增量数据要在窗口内补进来，如果窗口里还有外部系统的数据在写入，需要额外处理。
迁移本身的效率也有讲究。大批量表通常按主键或时间字段分片并行搬，大字段和索引往往留在最后统一重建，这比搬完数据再顺序建索引快。校验一般会做两层：先比对行数和主键范围，再做抽样或全量的字段比对，最终以业务口径的汇总数（例如某个月的订单总额）作为对外的确认依据。
方案二：双写并行过渡，逐步切读
双写指的是应用层同时往原库和国产库写数据，先用国产库承担只读流量做验证，确认没问题后再把写流量切过去、停掉原库。这种方式能把一致性风险分摊到一段时间里，而不是压缩到一个晚上。
- 优点：业务基本不停，切换过程可控，发现问题可以随时把读流量切回原库。
- 优点：有足够长的观察期，能把量不大的边界场景（并发冲突、时间精度、字符集差异）在真实流量下暴露出来。
- 缺点：应用改动量不小。写逻辑、事务边界、失败补偿都要处理，任何一个写入点漏掉双写都会造成数据缺口。
- 缺点：两库之间的自增主键、序列、时间戳在同一笔业务里可能不一致，后期做比对时容易误报，需要在数据模型层面提前约定。
- 缺点：过渡期内两边同时存在数据，运维和排查成本上升，排查问题时要先确认读的是哪个库。
双写适合写入路径集中、事务边界清晰的系统。写入路径分散在很多模块、每处都自己拼 SQL 的老系统，改造风险会明显放大。实际项目中常见做法是把写入收敛到一层数据访问代码里，再由这一层统一对外部库分发，避免每个业务模块各写各的。
这类协同层面的事情，和软件定制开发与系统集成服务中做接口与数据打通时的思路是一致的：先定边界，再定对账口径。
方案三：按模块分批迁移，逐块验收
对于系统模块耦合度不高的情况，可以按业务域拆开迁，比如先迁权限与组织数据，再迁档案类数据，最后迁交易类数据，每一块单独比对、单独验收。
- 优点：单次迁移的数据量小、范围可控，出问题的爆炸半径有限。
- 优点：验收口径清楚，每个模块迁完可以单独确认，不必等整体完成再验。
- 缺点：迁移期持续较长，跨模块的关联关系在过渡期内可能落在两个库里，要处理跨库查询或数据同步。
- 缺点：对模块划分质量要求高，划分不清的系统强行分批反而增加复杂度。
分批迁移的前提是模块边界与数据边界基本重合。如果表之间的外键和业务约束横跨多个模块，硬拆会把一致性问题从库内搬到库外，得不偿失。
什么情况下不要选这些方案
不是所有系统都适合直接对照上面的路径选。以下情况需要先处理别的问题，再谈迁移方案。
- 不要急着做双写，如果应用层写入逻辑分散、没有统一的数据访问入口。此时先做代码梳理和收敛，否则双写漏洞很难排查。
- 不要指望长停机窗口，如果业务是连续对外服务的，比如面向客户的在线下单或预约类系统。这类系统更适合双写加灰度切读。
- 不要分批迁移，如果核心交易数据高度集中在一两张宽表上，且模块之间强耦合。这种情况下切分带来的跨库问题会多于收益。
- 不要只做数据搬迁，如果原库里还有大量存储过程、触发器、自定义函数承担业务逻辑。这些逻辑要先迁出来放到应用层或重构，否则应用切换后行为会变。
- 不要省掉回退演练。无论选哪条路径，回退方案没演练过就不能正式切换。
决策建议：按四个问题定路径
实际选型可以按顺序回答四个问题。业务能接受的停机窗口有多长？存量数据量与增量写入速率大概在什么区间？应用层的写入入口是否集中？上下游还有多少系统连着这个库？四个问题的答案基本会把路径限定到一到两种。
- 能接受较长停机窗口，且原库数据规模适中，优先考虑停机一次性迁移。
- 几乎不能停，但写入入口集中，优先考虑双写并行过渡。
- 系统模块边界清晰，且迁移周期可以拉长，考虑按模块分批迁移。
- 上述都不满足，先把写入路径梳理和依赖清单做出来，再重新评估。
无论走哪条路，数据一致性都不只靠迁移工具。建议在正式迁移前用真实数据的副本做一次完整演练，把校验脚本、比对口径、回退步骤都跑通。政府与国企类项目还要考虑文档与验收要求，可参考我们
政府与国企国产化改造案例中的交付方式，作为内部方案评审的参照。
文字版对比清单
- 停机一次性迁移 → 适合能安排低峰停机窗口、写入入口相对集中的系统 → 主要代价是窗口时长不可控，校验时间容易被压缩。
- 双写并行过渡 → 适合几乎不能停、写入路径收敛在统一数据访问层的系统 → 主要代价是应用改造量大，过渡期排查成本高。
- 按模块分批迁移 → 适合模块边界与数据边界重合、迁移周期可拉长的系统 → 主要代价是过渡期跨库关系处理，验收周期拉长。
一致性验收的分层检查项可以参考下面的顺序，从库内到业务口径逐层往上查。
- 表级：行数、主键范围、空值分布是否与原库一致。
- 记录级：按主键或时间片抽样比对关键字段，重点关注金额、时间、状态。
- 关联级：外键与业务关联关系在迁移后是否完整，有无孤儿记录。
- 业务级：按业务口径汇总核对，例如某个期间的订单数、入账金额。
迁移完成不等于项目结束。上线后的一段时间里，建议保留原库只读，与国产库做定时比对，确认无差异后再做下线处理。这个阶段的运维交接与日常巡检，可以纳入服务范围与交付流程中的运维环节统一安排。
