从 SQL Server 迁到国产数据库，语法差异只是表层，真正拖慢进度的是分页写法、隐式类型转换、存储过程逻辑和处理空值的语义差异。落地时通常有三条路线：开启兼容模式少改、逐条改写 SQL、在中间层做适配。三种做法没有优劣之分，取决于存量 SQL 规模、团队维护能力与改造时间窗。
方案一：启用兼容模式，尽量少改 SQL
不少国产库提供面向 SQL Server 的兼容开关或兼容模式（具体形态视版本而定），让部分原有语法直接运行。常见做法是在 POC 阶段把核心报表和关键流程跑一遍，统计哪些语句不用改、哪些报错。
- 优点：改动量小，业务代码基本不动，适合时间紧、存量 SQL 多的项目。
- 优点：回归测试范围可控，上线风险集中在数据库侧。
- 缺点：兼容层覆盖有限，冷门函数、复杂存储过程和窗口函数容易落在边界外。
- 缺点：长期依赖兼容模式，后续升级和调优空间受限，迁移经验也沉淀不下来。
这类路线适合以「先跑起来」为第一目标的政府与国企国产化改造项目。政府与国企国产化改造案例里的迁移场景，多数也是先保业务连续，再逐步清理兼容依赖。
方案二：逐条改写 SQL，彻底去除源库依赖
第二种做法是不依赖兼容模式，把分页、字符串拼接、日期函数、类型转换、空值判断逐项改写为目标库的标准写法。工程上建议先做语句清单：从应用日志、慢查询记录和代码扫描中导出全部 SQL，按调用频率与业务重要度分级。
- 先改高频核心语句，再处理低频报表与后台任务。
- 每条改写都配一条对照用例，用同一批数据比对结果集。
- 存储过程和触发器重点评审，逻辑复杂时优先考虑下沉到应用层。
- 改写完成后统一做一次全量回归，而不是只测改动点。
代价是工作量和测试成本明显上升，且要求团队同时熟悉两种数据库。收益是系统不再绑定特定厂商，后续换库或双库并行都更从容。
方案三：中间层适配，把差异收在一处
第三种是在数据访问层做适配，通过统一的数据访问组件、视图或轻量代理，把方言差异集中处理。应用侧尽量写标准 SQL，差异部分由适配层转换。
- 优点：差异集中，排查问题有固定入口，适合多系统共享一套数据访问代码的场景。
- 优点：便于双库并行运行，迁移期可以做灰度切换与结果比对。
- 缺点：适配层本身要开发和维护，抽象不当会掩盖性能问题。
- 缺点：复杂语句经过转换后执行计划可能变差，需要专门做压测。
需要同时保留原库与新库一段时间、或存在多个业务系统共用数据库的情况，这条路线更稳妥。具体的分层设计与联调安排，可以参考软件定制开发与系统集成服务中的交付方式。
什么情况下不要选兼容模式
兼容模式解决的是「能跑」，不是「跑得好」。出现以下情况时，建议直接走改写路线，不要指望兼容层兜底：
- 系统重度依赖存储过程与触发器，逻辑层层嵌套，兼容层很难完整覆盖。
- 存在大量复杂报表 SQL，涉及多层子查询、窗口函数与自定义函数。
- 后续有性能调优与容量规划要求，需要数据库按目标库的最佳实践执行。
- 项目验收明确要求去除对源库语法特性的依赖，兼容开关本身不被认可。
反过来，如果系统以简单增删改查为主、改造窗口很短，兼容模式可以作为过渡，但要同步排一份清理计划，避免长期停留在兼容状态。
落地时的常见兼容性坑与处理建议
不管选哪条路线，下面几类问题在 SQL Server 迁国产库时反复出现，建议在开发联调阶段就纳入检查项。分页语法是第一个要处理的地方，不同库对偏移量与排序稳定性的要求不同，缺少稳定排序时分页结果可能重复或遗漏。
其次是隐式类型转换。源库对字符串与数字的比较比较宽松，目标库往往更严格，索引也可能因此失效——建议统一参数类型，避免在字段上套函数。再有是空值参与运算与聚合的语义差异，统计口径容易在不知不觉中变化。
时间与日期函数、字符串截取与拼接、自增列与序列的取值方式，也都属于需要逐条核对的范畴。这部分细节较多，更多技术实现细节里有按主题整理的实践说明。
验收清单：迁移是否真正完成
迁移验收不宜只看「系统能打开」，建议从以下几条逐项确认，再进入运维交接：
- 全部 SQL 已有清单，逐条标注「未改 / 已改写 / 走适配层」。
- 核心流程与关键报表有结果集比对记录，差异项已说明原因。
- 分页、排序、聚合统计在边界数据下的结果与原库一致。
- 主要查询在目标库上有执行计划评审，无异常全表扫描。
- 备份恢复、监控告警、账号权限已按目标库方式配置完成。
- 兼容模式若仍开启，已列出清理计划与责任人。
准备进入实施阶段时，可以先看同类项目案例了解交付节奏，再结合自身存量 SQL 规模确定路线。
文字版对比清单
- 兼容模式：适合时间紧、以简单查询为主、需要快速上线的项目；主要代价是覆盖有限、长期依赖兼容层。
- 逐条改写：适合存储过程多、报表复杂、有长期维护要求的系统；主要代价是工作量大、测试成本高。
- 中间层适配：适合多系统共用、需要双库并行与灰度切换的场景；主要代价是适配层要自行开发维护。
更多方案与交付安排可见服务范围与交付流程，也可以直接联系我们沟通具体场景。
常见问题
兼容模式开启后，原有 SQL 是否就不用改了？
一般不能这样认为。兼容模式覆盖的是常见语法，复杂语句仍可能报错或结果不一致，建议在 POC 阶段把核心语句实测一遍，再决定改动范围。
存储过程应该整体改写，还是拆到应用层？
视逻辑复杂度而定。业务规则简单、调用频繁的可以改写到应用层；逻辑复杂且与数据强相关的，建议在目标库重写并单独做回归测试。
迁移期间能否两套数据库并行？
可以，常见做法是新旧库同时写入或按业务灰度切换，用结果比对来验证一致性。代价是要处理数据同步与冲突，测试周期也会拉长。
