国产数据库迁移：真正花时间的从来不是搬数据
内容提要
国产化数据库迁移中，数据搬迁耗时不足20%，约80%耗在语法改写、存储过程翻译和双轨验证上。建议按评估15%、应用改造50%、双轨25%、割接10%分配工作量。评估阶段应先全量扫描SQL、列出对象清单并跑真实压测。常见坑包括分页改写、空串等于NULL、数值精度和外键校验。双轨期需关注数据一致性、性能基线和回退方案。对深度绑定数据库特性或规模过小的系统应劝退。
延伸解读
工作量分布：应用改造才是主战场
文章基于四个项目统计，兼容性评估约15%、应用改造约50%、双轨运行约25%、割接切换约10%。数据搬迁本身不到20%，且工具能覆盖七成。这意味着项目排期和人力应重点投向SQL改写、存储过程翻译与双轨验证，而非数据导出导入方案。把评估阶段草草了事，后续改造和验证会成倍放大风险。
评估阶段的三步顺序不能反
先全量扫描SQL（含视图、触发器、存储过程、动态拼接），产出不兼容语法清单；再列对象清单，重点看索引类型、分区策略、主键定义，避免DDL返工；最后用核心场景典型数据量做真实压测，暴露连接数、并发上限等功能测试看不出的问题。跳过压测，问题会留到双轨或割接时才爆发。
高频坑点：分页、空串、精度、外键
分页改写需拿生产数据比对结果，不能只对条数；空字符串可能被存成NULL，改变代码分支，测试环境因数据全空值少而难复现；NUMBER未指定精度标度迁到NUMERIC可能变成38位小数，影响表体积和索引效率，应显式指定NUMERIC(p,s)；外键默认不校验导入数据，需显式开启，否则脏数据割接后才暴露。
双轨期盯三件事，劝退也是决策
双轨期要按主键全量比对数据一致性并保留差异表作为证据链；用同一压测脚本记录新旧库p95/p99差异，国产库连接池常需单独调；回退方案要提前定，旧库只读保留至少7天、连接串可热切换。深度绑定数据库特性或规模过小的系统，翻译成本远超收益，应评估后劝退，这是投入产出决策而非纯技术判断。
Q&A
国产数据库迁移项目的时间主要花在哪些环节？
根据多个项目统计，数据搬迁本身耗时不到20%，约80%的时间花在语法改写、存储过程翻译和双轨验证上。具体分布大致为：兼容性评估15%、应用改造50%、双轨运行25%、割接切换10%。
迁移评估阶段应该按什么顺序做哪些事？
评估阶段应顺序做三件事：第一，全量扫描SQL语句（包括视图、触发器、存储过程、动态SQL），产出不兼容语法清单；第二，列出对象清单，重点检查索引类型、分区策略、主键定义方式；第三，用核心场景的典型数据量跑真实压测，提前暴露连接数、并发上限等问题。
国产数据库迁移中常见的坑有哪些？
常见坑包括：分页写法改写（ROWNUM嵌套改LIMIT/OFFSET时层级和ORDER BY位置易错）；空字符串被存成NULL导致代码逻辑分支变化；数值精度未显式指定（如NUMBER映射为NUMERIC时需指定精度和标度）；外键约束默认不校验导入数据，需显式开启校验。
双轨运行期间需要重点关注哪些指标？
双轨期应盯三个指标：数据一致性（按主键全量比对，增量按时间窗口拉取，保留差异表作为证据链）；性能基线（用同一压测脚本对比p95和p99差异，注意连接池配置需单独调优）；回退方案（割接后旧库保留只读至少7天，连接串支持热切换）。
哪些系统不建议进行国产数据库迁移？
两类系统建议劝退：一是深度绑定数据库特性的系统（大量使用数据库特有包、动态SQL、系统视图），翻译成本远超重写成本且难以验证正确性；二是规模特别小的系统（数据量仅几百MB、查询简单），迁移收益覆盖不了改造成本，保留原库做只读归档更合理。
如何判断一个迁移项目是否成功？
最终看割接当天的回滚次数。回滚为零的项目，说明前期的评估和双轨工作扎实。
