SQLServer数据库迁移实录：十年老系统搬上 KingbaseES，T-SQL 基本没重写

三月份接了个活，SQLServer数据库迁移，把一套 2012 年左右上线、前后迭代了十来年的业务系统从 SQL Server 挪到国产库上。

第一次开评估会，屋里坐着六七个 DBA 和开发。数据怎么搬没人愁，工具现成。聊到应用层的时候气氛就不对了------我拿 SSMS 导了份对象清单投在屏幕上，存储过程八百三十七个，触发器小两百，视图函数另算，全是 T-SQL。坐我旁边的老王盯着那行数字看了半天，蹦出来一句："这得改到后年去吧。"

结果两个月后系统切流，那八百多个存储过程，绝大多数一个字符没动，原样跑在 KingbaseES（后文都叫 KES）上。真正改了的是一小撮，而且基本是工具先改完、我们核对。这篇文章写写这里面的门道：KES V9R4C019 到底吃下了哪些 T-SQL 语法，凭什么存量代码能直接跑，还有 KDMS 工具在中间起了什么作用。

钱花在哪儿，先算清楚

迁移项目拆开就三块：结构、数据、应用。前两块自动化程度高，跑脚本的事。第三块才是吞人力的------SQL 跟存储过程适配，T-SQL 方言跟目标库每差一处，就是一次改写加一轮回归。代码存量越大，坑越深。

所以路线问题上我们没怎么纠结。改应用去凑新库？八百多个存储过程逐条重写，还要保证不改出 bug，谁也不敢拍这个胸脯。那就剩另一条路：让库去兼容语法，代码原样跑，人从"改代码"变成"验代码"。KES 走的就是这条，内核层做 T-SQL 深度兼容，KDMS 负责迁移前的评估和残留差异的转换。能不改就不改，非改不可的机器先改。

这些语法，我们是真用上了

兼容值不值钱看覆盖面。我不罗列宣传口径，只说项目里实际撞上的几类------巧了，全是 V9R4C019 补齐的。下面代码都是系统里的标准 T-SQL 写法，在 KES 的 SQL Server 兼容模式下直接执行通过。

MERGE

做 ETL 的没法绕开"有则更新、无则插入"。我们的客户同步作业里，T-SQL 的 MERGE 长这样：

sql 复制代码

MERGE INTO dbo.customer AS t
USING staging_customer AS s
ON t.cust_id = s.cust_id
WHEN MATCHED THEN
    UPDATE SET t.cust_name = s.cust_name,
               t.update_time = GETDATE()
WHEN NOT MATCHED THEN
    INSERT (cust_id, cust_name, update_time)
    VALUES (s.cust_id, s.cust_name, GETDATE());

迁之前我专门扫了一遍代码库，MERGE 出现了四十多处，集中在同步类存储过程里。当时最担心的就是它，因为换成不支持的库，这段就得拆成 UPDATE 加行数判断再加 INSERT，并发下的竞态还得自己兜。实测结果：四十多处全部直接跑通，一处没改。

OUTPUT 子句

审计留痕场景的重度用户。增删改执行的同时把受影响行吐出来，INSERTED、DELETED 两张虚表，改前改后的值全齐：

sql 复制代码

DECLARE @audited TABLE (order_id INT, old_amount MONEY, new_amount MONEY);

UPDATE dbo.orders
SET amount = amount * 0.95
OUTPUT DELETED.order_id, DELETED.amount, INSERTED.amount
    INTO @audited
WHERE order_date < '2026-01-01';

我们订单模块靠这个写法做变更审计，一条语句干完业务变更加日志。迁移验证时这块直接过。老王后来闲聊说，他本来都做好了"先查再改再写日志"三步重写的思想准备，白做了。

窗口函数

报表模块的骨架。ROW_NUMBER、RANK、SUM OVER 这套，排名分页累计环比全靠它：

sql 复制代码

SELECT cust_id,
       order_id,
       amount,
       ROW_NUMBER() OVER (PARTITION BY cust_id ORDER BY order_date DESC) AS rn,
       SUM(amount)  OVER (PARTITION BY cust_id) AS cust_total
FROM dbo.orders;

代价我领教过。一九年帮另一个系统做异构改写，拿自连接模拟窗口，SQL 从十几行膨胀到七八十行，跑起来还慢一截。所以这回验证，我头一批抽的就是报表查询。V9R4C019 把 OVER、PARTITION BY 这套完整接下来了，分析型 SQL 原样平移。

PIVOT / UNPIVOT

财务交叉报表的刚需，行转列、列转行的双向语法：

sql 复制代码

SELECT cust_id, [2024], [2025], [2026]
FROM (
    SELECT cust_id, YEAR(order_date) AS yr, amount
    FROM dbo.orders
) AS src
PIVOT (
    SUM(amount) FOR yr IN ([2024], [2025], [2026])
) AS p;

财务那几张年度汇总表，恰好就是这种写法。验证那天我把新旧两库跑出来的结果并排摆着，一格一格对过去，行列位置分毫不差。这要是搁在不支持 PIVOT 的库里，就只能 CASE WHEN 配 GROUP BY 硬拼------一九年那回我干过，一条 SQL 写一下午，写完眼都是花的。

并行 DML

语法通是底线，批量活还得跑得快。历史数据归档那类作业，一条 UPDATE 下去几千万行。V9R4C019 的并行 DML 让大批量 INSERT、UPDATE、DELETE 多线程并行跑，我们归档作业迁完后的执行时间跟原库在一个量级，没出现"能跑但跑不动"的尴尬。

LIKE 通配符

压轴说 LIKE，我觉得这是最能看出兼容深度的一处。起因是编码规则校验那块用了一堆花式匹配，我不放心，把 SQL Server 里 LIKE 的几种吃法挨个列出来逐条验：

sql 复制代码

WHERE cust_name LIKE '张%'           -- 前缀匹配
WHERE cust_name LIKE '_伟'           -- 单字符通配
WHERE code LIKE '[A-Z]%'             -- 字符集：以字母开头
WHERE code LIKE '[^0-9]%'            -- 否定字符集：不以数字开头
WHERE path LIKE '%\%%' ESCAPE '\'    -- ESCAPE 转义：匹配字面量 %

% 和 _ 哪家都认，但 [A-Z] 区间集合、[^0-9] 否定集合，不少数据库的 LIKE 根本不支持。我们编码规则校验那块的代码正好用了否定集合，我单拎出来逐条测的，全对。兼容从语句级做到运算符语义级，就是这个意思。

"零修改"这话得说全

上面几类拼起来，恰好盖住了 T-SQL 业务代码的高频面：存储过程里的 MERGE、触发器里的 OUTPUT、报表里的窗口函数和 PIVOT、批量作业的大 DML、散落的 LIKE。所以"绝大多数直接跑"不是客套话，是我们验证出来的。

但也别理解成百分之百。准确口径是"零修改或极少修改"：语法语义层的差异内核消化掉了，个别跟源库平台绑死的东西------某些系统视图、私有 hint 之类------迁移工具在评估阶段就会识别，列进报告给改写方案。我们的活从逐行改代码，变成对着报告核清单。改造量从八百多个对象的量级，缩到一张清单的量级。做过迁移的人知道这意味着什么。

KDMS 在中间干了什么

内核兼容管"大部分不用改"，KDMS 管"工程怎么落地"。这部分我以《产品说明书-金仓迁移工具 KDMS》为准，掺一点我们的用法。

说明书上对 KDMS 的定位就一句话：把 DB2、Oracle、SQL Server、MySQL 这些主流库迁到 Kingbase。架构走的是"云+端+服务"，操作上一键发起。它具体干的活，我按我们当时的使用顺序讲。

评估阶段，采集软件连源库采结构对象，只采结构不碰业务数据，跑完出一份《迁移评估报告》。兼容性量化指标、风险点，开工前就摆桌面上。立项会上领导必问的"这系统迁过去要动多少东西"，拿报告回答，比拍脑袋强。

转换阶段，路子是解析源库 SQL、PL/SQL 的语义，变成结构化的逻辑对象，再按目标库语法和对等函数生成能跑的脚本。语言级翻译，不是字符串替换，这个区别很关键。速度我没掐表测过，说明书给的数据是每分钟 20 万行以上的 SQL/PLSQL 代码。多人协同倒是真用上了，我们三个人按模块分工核的对象。转换完自动生成目标库脚本，附带 SQL 智能优化和改写建议。

还有个低门槛设计我印象不错：用的人不需要掌握目标库语法，跟着转换结果就能完成对象迁移和验证。卡壳了走工单找 DBA 支持。信创环境也齐，飞腾芯片、银河麒麟 V10 都在支持列表里，我们就是在麒麟环境上跑的。

过程拢共四步

评估，KDMS 采结构出报告，先摸清风险点。转换，照报告做对象智能转换，目标侧脚本自动出来。验证，存量 T-SQL 直接跑，重点回归存储过程、触发器、报表查询，报告里列的差异点逐条核。最后割接，结构就位，业务数据由配套迁移环节承接，切流上线。

跟以前做过的迁移比，节奏完全两样：以前是拉一票人闷头重写 SQL，这次是评估一轮、验证一轮。周期和人力都是这么压下来的。

最后两句

绕回开头的问题。SQL Server 迁移难在哪？不在搬数据，在改代码。V9R4C019 把 MERGE、OUTPUT、窗口函数、PIVOT/UNPIVOT、并行 DML 这批高频语法补齐，颗粒度细到 LIKE 通配符那层，存量 T-SQL 才做到基本不动；KDMS 拿评估加自动转换，把剩下的差异点收成一张清单。

你要是也在掂量这事，我的建议就一句：拿自己的库先跑一次评估。报告里的数字，比任何文章都诚实------包括我这篇。