SQL Server 迁移的五个技术难点与金仓的解决方案

　　SQL Server 在医疗、海关、政务、制造等领域用得深，国产化替代过程中有它独特的技术难点。这些难点的根源，不是因为 SQL Server 的功能有多复杂，而是因为很多开发者已经习惯了它那些"非标准但好用"的特性。迁移的时候，要兼顾两件事：让数据库换掉，让开发者不用改习惯。

　　金仓数据库 KingbaseES 的 SQL Server 兼容产品化版本就是为了解决这个问题上线的。

　　GO 批处理、无分号、临时表——这五道坎怎么过

　　SQL Server 的迁移不像 MySQL 或 PostgreSQL，它有一整套"非标准"的设计，正是这些设计让迁移变得棘手。核心难点有五个。

　　事务模式是第一个。SQL Server 支持自动提交、显式、隐式三种运行模式，不同模式下事务的开启和提交行为完全不同。应用代码可能是基于其中任意一种模式开发的，迁移时必须精确还原原有的事务行为，否则就会出现数据不一致。

　　GO 批处理是第二个。GO 命令是 SQL Server 特有的批处理分隔符，在 SSMS 里被广泛使用。它把一组 SQL 语句打包成一个逻辑单元执行，每个单元独立编译。这不是标准 SQL，其他数据库通常不支持，而大量 SQL Server 的运维脚本和存储过程里到处都是 GO。

　　无分号分隔是第三个。SQL Server 允许在一个查询窗口里输入多条不带分号的 SQL 语句并一次执行。这实际上是一个很"用户友好"但完全不符合 SQL 标准的设计，问题是它已经成了数百万开发者的肌肉记忆。

　　临时表和 IDENTITY 是第四个。全局临时表(##temp)、本地临时表(#temp)、IDENTITY 自增列这些功能，在其他数据库里有近似的替代方案，但行为细节往往有差异。迁移时如果只是简单替换，可能在边界情况出问题。

　　多表联合 DML 是第五个。SQL Server 的 FROM 子句允许在 UPDATE 和 DELETE 语句中关联多张表，这在标准 SQL 中是不支持的写法。代码迁移量大的时候，这种语法的转换工作不可忽视。

　　SQL 层怎么兼容，从三种事务到多表 DML

　　针对这些难点，金仓 KES 在 SQL 层做了逐一处理。

　　事务控制方面，通过 implicit_transactions 参数可以设置三种事务模式，跟 SQL Server 的行为完全对应。全局变量 @@TRANCOUNT、事务函数 XACT_STATE()、CURRENT_TRANSACTION_ID()、CURSOR_CLOSE_ON_COMMIT() 全部支持，包括嵌套事务的 BEGIN TRAN、COMMIT、ROLLBACK、SAVE 这些语句。

　　GO 批处理方面，KES 在 SQL 层和 PL/SQL 层都支持 GO 命令。开发者可以用 ksql、KStudio 或客户端编程接口执行 GO 分隔的批量 SQL。GO 后面加数字，还可以重复执行前面的批处理——这个用法在 SQL Server 里非常常见，KES 也原样支持。

　　无分号分隔和多条 SQL 一次执行，KES 在 SQL Server 兼容模式下也支持。开发者不需要逐个给语句加分号。

　　IDENTITY 自增列完全兼容。全局和本地临时表的生命周期和访问范围跟 SQL Server 一致。FROM 子句的多表联合 UPDATE 和 DELETE 也做了支持。

　　这五个难点的处理方式的共同思路是：不去尝试"改进"或"标准化" SQL Server 的用法，而是尽可能原样还原，让迁移对开发者透明。

　　不止兼容语法，工具生态和底层架构也换了

　　数据库迁移的价值不应该只是"语法能跑了"，工具链和底层架构的适配同样重要。

　　工具生态方面，金仓提供了一套跟 SQL Server 工具链对标的方案。KDMS 对标 SSMS 的评估功能，自动扫描源端数据库和应用代码，生成兼容性报告和改造建议。KDTS 做一键迁移，把自动化程度做到最高。KFS 做 SQL Server 到 KES 的实时增量同步，保证不停机迁移。KStudio 对标 SSMS 的日常管理功能，提供有相似体验的图形化管理界面。

　　体系架构层面的兼容更底层。KES 在五个维度上与 SQL Server 对齐：

　　存储结构，数据页、区、段的组织方式;

　　逻辑结构，数据库、表空间、表的层级关系;

　　进线程结构，进程和线程的管理模型;

　　查询处理体系，查询计划的生成和优化机制;

　　事务处理机制，隔离级别、锁机制和并发控制。

　　语法兼容保证代码能跑，工具兼容保证开发效率不降，架构兼容保证迁移后的性能表现。三层合在一起，才是一个完整的迁移方案。

　　评估、迁移、校验——三步走完

　　迁移流程本身被拆成了三步，每一步都有对应的工具。

　　第一步是 KDMS 评估。在正式迁移之前，对 SQL Server 源端做全面采集，数据库结构、数据量、存储过程、触发器、应用代码中的 SQL 语句、运行中的动态 SQL。评估引擎融合了 KES 的语法解析逻辑，能精确识别兼容差异，自动分类，完全兼容的、部分兼容需要微调的、需要改造的、目前不支持的。基于对象数量和复杂度，还会估算改造工作量，提示关键风险点。

　　第二步是 KDTS 全量迁移。评估通过后，批量迁移存量数据。KDTS 会自动做对象翻译，SQL Server 的存储过程、函数、触发器自动转换为 KES 兼容格式。数据类型映射也自动完成。整个过程不需要手动写转换脚本。

　　第三步是 KFS 增量同步。全量迁移完成后，KFS 接管增量数据，通过解析 SQL Server 事务日志实现亚秒级同步。同步期间持续在线校验数据一致性，在业务低峰期完成最终切换。

　　这三步的设计逻辑是"风险前置"，把不确定性放在评估阶段解决掉，让后面的迁移和切换变成确定性操作。

　　三个容易被忽略的细节：事务、批处理、分号

　　前面的五个难点在 SQL 层已经处理了，但事务、批处理和分号这三个细节值得单独展开，因为在实际迁移中最容易在这几处踩坑。

　　事务处理。KES 在 SQL 层和 PL/SQL 层都实现了完整的 SQL Server 事务兼容。通过 implicit_transactions 参数控制事务模式，支持 @@TRANCOUNT、XACT_STATE()、CURRENT_TRANSACTION_ID() 等全局变量和函数。BEGIN TRAN、COMMIT、ROLLBACK、SAVE 以及嵌套事务的语法和行为跟 SQL Server 一致。

　　GO 批处理。KES 把 GO 命令的实现做进了 SQL 层和 PL/SQL 层，不仅仅是语句分隔符层面的兼容，而是完整保留了 GO 的批处理逻辑，每个 GO 之间的语句被编译为单一执行计划，可以被系统缓存，重复执行时不需要重新编译。这是一个性能相关的细节，做不好会影响执行效率。

　　无分号分隔。KES 在 SQL Server 兼容模式下允许不使用分号分隔语句。看起来是个小功能，但它让 SQL Server 开发者迁移过来的时候不需要改书写习惯。减少摩擦，迁移阻力就小。

　　这三个细节并不是独立的技术点，而是同一个设计原则的三个体现：尊重开发者的既有习惯，不强迫他们改变工作方式。

　　11 个系统一次迁移，一台 PACS 的 2 秒响应

　　某省级环保集团的全栈替代项目是一个典型的多系统迁移案例。环保一体化、OA、数据中台等 11 个核心业务系统从多款异构数据库(其中包括 SQL Server)整体迁移到金仓。采用的正是 KDMS 评估、KDTS 全量迁移、KFS 增量同步的标准流程，整个迁移期间业务没有中断。

　　另一个有代表性的案例是浙江省人民医院的 PACS(影像归档与通信系统)国产化改造。这个项目由金仓和杭州迈瑞数字科技共同完成。PACS 系统里存储着海量的医学影像数据，对查询响应速度的要求非常高，医生调阅 CT 影像不能等。KES 对 Oracle 和 SQL Server 语法的高度兼容性，让这个项目的应用层核心代码基本不需要改动。在迁移策略上，团队采用了离线全量加在线增量的组合方案，影像调阅在复杂场景下的响应时间控制在 2-3 秒以内。

　　这两个案例放在一起看，说明了两件事：多系统批量迁移是可行的，前提是有标准化的评估和迁移流程;高要求的单系统迁移也是可行的，前提是有足够的兼容深度和灵活的迁移策略。

　　写在最后

　　SQL Server 迁移的难点不在于"怎么搬数据"，而在于"怎么让开发者不用改习惯"。

　　金仓的兼容方案覆盖了从 SQL 语法到事务机制、从工具生态到体系架构的多个维度。这个方案的前提假设是：一套数据库在业务系统里跑了多年之后，它的价值不只是数据，还有围绕它建立起来的一整套运维流程、开发习惯和排障经验。迁移如果要成功，就不能只迁移数据，还要尽可能保留这个生态。

　　对于已经稳定运行多年的 SQL Server 业务系统来说，迁移的价值也不只是换一个国产数据库，它也是一次重新审视数据架构的契机：存储结构是否合理，索引策略是否需要调整，查询写法有没有优化的空间。迁移不是终点，而是一次升级。