SQL Server数据库迁移最怕什么？存量T-SQL代码一行不改，金仓KES V9R4C019给出了答案

做数据库国产化替代这几年，我接触过不少做SQL Server数据库迁移的团队。聊得多了会发现一个规律：真正让人头疼的从来不是"把数据搬过去"这一步，而是搬完之后那一地鸡毛——几万行甚至几十万行的存量T-SQL存储过程、函数、报表SQL，到底要不要重写？

这事说大不大，说小不小。数据迁移工具跑一个晚上就能完成，但代码改造动辄按人月算，改完还要回归测试，业务方等不起。所以很多客户在选型的时候，第一个问题不是"性能怎么样"，而是"我的代码过去之后，到底能直接跑多少"。

金仓KES V9R4C019这个版本，就是冲着这个问题来的。它的思路很明确：把SQL Server的核心语法特性补齐，让存量T-SQL代码直接运行，业务逻辑一行不动。这篇文章我把里面的关键特性挨个过一遍，配上代码，大家自己判断这套兼容做到了什么颗粒度。

一、先看最基础的：建表和增删改查，能不能原样跑

迁移的第一关是DDL。SQL Server的建表语句里有些"特产"，比如IDENTITY自增列、NVARCHAR、默认值里用GETDATE()，这些在别的数据库里往往要手工改写。在KES V9R4C019里，这些写法是可以直接落地的。

先建一张订单表：

CREATE TABLE Sales.Orders (
    OrderID     INT IDENTITY(1,1) PRIMARY KEY,
    CustomerID  INT NOT NULL,
    OrderNo     NVARCHAR(32) NOT NULL,
    OrderDate   DATETIME NOT NULL DEFAULT GETDATE(),
    Amount      DECIMAL(18,2) NOT NULL,
    Status      TINYINT NOT NULL DEFAULT 0
);

IDENTITY(1,1)、GETDATE()这些写法，都是从SQL Server那边原样抄过来的，不需要改成别家的自增语法和时间函数。对做迁移的人来说，这意味着建表脚本可以批量导入，几百张表的DDL脚本不用逐张过眼。

再看DML。插入一批测试数据：

INSERT INTO Sales.Orders (CustomerID, OrderNo, OrderDate, Amount, Status)
VALUES (1001, 'SO-20260301-001', '2026-03-01 09:15:00', 12800.00, 1),
       (1001, 'SO-20260302-011', '2026-03-02 14:30:00', 4600.00, 1),
       (1002, 'SO-20260303-007', '2026-03-03 10:05:00', 23500.00, 2),
       (1003, 'SO-20260305-002', '2026-03-05 16:45:00', 890.00, 0),
       (1002, 'SO-20260308-019', '2026-03-08 11:20:00', 15700.00, 1);

查询的时候，SQL Server用户最顺手的几个写法——TOP、ISNULL、方括号包对象名——都能保留：

SELECT TOP 10 OrderID, OrderNo, ISNULL(NULLIF(Status, 0), 9) AS StatusFlag, Amount
FROM Sales.Orders
WHERE OrderDate >= '2026-03-01'
ORDER BY Amount DESC;

更新和删除也是同样待遇，UPDATE ... FROM ... JOIN这种SQL Server特色联表更新写法不用拆开重写：

UPDATE o
SET o.Status = 2
FROM Sales.Orders AS o
JOIN Sales.Customers AS c ON o.CustomerID = c.CustomerID
WHERE c.City = N'杭州' AND o.Status = 1;

DELETE FROM Sales.Orders
WHERE OrderDate < '2025-01-01' AND Status = 9;

基础语法这一层如果都要改，那存量代码就别想省事了。V9R4C019把这个底座打牢之后，才谈得上后面那些更复杂的特性。

二、MERGE语句：数据同步场景的硬需求

做数仓和做业务系统的人都离不开MERGE。一张目标表，一张来源表，匹配上的更新，匹配不上的插入，一条语句搞定，这在SQL Server上是用了十几年的标准操作。

问题在于，很多数据库不认这条语句，迁移过来只能拆成"先UPDATE再补INSERT"，还得处理并发下的重复插入问题。而在KES V9R4C019里，MERGE是原生支持的：

MERGE INTO Sales.Orders AS target
USING Staging.OrdersDelta AS source
ON target.OrderNo = source.OrderNo
WHEN MATCHED THEN
    UPDATE SET target.Amount = source.Amount,
               target.Status = source.Status
WHEN NOT MATCHED THEN
    INSERT (CustomerID, OrderNo, OrderDate, Amount, Status)
    VALUES (source.CustomerID, source.OrderNo, source.OrderDate, source.Amount, source.Status);

跑一遍，匹配到的订单更新金额和状态，新订单直接插进去。原来写在SQL Server作业里的同步存储过程，整段拷过来执行，逻辑不用动。

三、OUTPUT子句：写操作顺手拿到变更数据

OUTPUT是T-SQL里特别能体现"顺手"二字的特性。UPDATE、DELETE的时候想顺手拿到被改了、被删了哪些行？在SQL Server里加一句OUTPUT就行，不用先SELECT出来存临时表再操作。

V9R4C019把这个子句也补上了。比如删除历史订单时留个底：

DELETE FROM Sales.Orders  
OUTPUT DELETED.OrderID, DELETED.OrderNo, DELETED.Amount  
WHERE OrderDate < '2025-01-01;

再看更新：

UPDATE Sales.Orders
SET Amount = Amount * 0.9
OUTPUT INSERTED.OrderNo, DELETED.Amount AS OldAmount, INSERTED.Amount AS NewAmount
WHERE Status = 1 AND Amount > 20000;

INSERTED、DELETED这两个逻辑表的行为和SQL Server保持一致。审计、对账类的存储过程里这类写法很常见，能原样跑，省掉的是实打实的改造工作量。

四、窗口函数和PIVOT/UNPIVOT：报表SQL的半壁江山

报表系统的SQL往往是迁移的重灾区，因为里面全是窗口函数。ROW_NUMBER、RANK、移动平均、累计求和，一页SQL里七八个OVER()子句叠着用。这类SQL手改是最痛苦的：业务逻辑埋在函数嵌套里，改错一个参数，报表数字就不对了。

KES V9R4C019对窗口函数做了完整支持。给每个客户的订单按金额排序打标：

SELECT OrderID, CustomerID, Amount,
       ROW_NUMBER() OVER (PARTITION BY CustomerID ORDER BY Amount DESC) AS rn,
       SUM(Amount) OVER (PARTITION BY CustomerID) AS CustomerTotal,
       AVG(Amount) OVER (PARTITION BY CustomerID ORDER BY OrderDate
                         ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS MoveAvg
FROM Sales.Orders;

用ROW_NUMBER取每组第一条这种最常见的写法（子查询里筛rn = 1）也完全没问题。

还有PIVOT和UNPIVOT，做月度汇总、行列转换的报表SQL里出现频率极高：

SELECT CustomerID, [1] AS Q1, [2] AS Q2, [3] AS Q3
FROM (
    SELECT CustomerID, DATEPART(QUARTER, OrderDate) AS Qtr, Amount
    FROM Sales.Orders
) AS src
PIVOT (SUM(Amount) FOR Qtr IN ([1], [2], [3])) AS pvt;

方括号包列名、DATEPART取季度，这些细节全部按T-SQL的习惯来。报表SQL不动，意味着迁移之后报表口径不会有偏差，这在业务方那里是最敏感的一点——数字错了，什么都白搭。

五、并行DML：大批量数据处理不再干等

有些迁移过来的系统，夜里要跑大批量数据加工任务，动辄几百万行的UPDATE和INSERT。如果DML只能单线程跑，白天业务开始之前任务还没结束，就是事故。

V9R4C019支持并行DML，大批量增删改可以利用多核并行执行。对用户来说这不需要改任何代码，语句还是原来那条语句，执行引擎自己决定怎么并行。配合并行查询，原本跑三小时的日终任务压到几十分钟，第二天早上业务人员打开系统，数据早就备好了。

六、LIKE通配符：兼容颗粒度的一块试金石

特性列表看多了容易麻木，真正体现兼容深度的反而是那些不起眼的角落。LIKE就是典型。

SQL Server的LIKE除了%和_，还有方括号区间匹配，比如LIKE '[a-c]%'表示以a、b、c开头，方括号里加^表示取反，LIKE '[^0-9]%'匹配不以数字开头的字符串。这些写法在别的数据库里大多不被支持，碰到就得改写成一堆OR条件，或者换正则函数，SQL越长越难维护。

在KES V9R4C019里，这些通配符按SQL Server的行为支持：

-- 匹配以字母开头的单号
SELECT * FROM Sales.Orders WHERE OrderNo LIKE '[A-Z]%';

-- 排除以数字开头
SELECT * FROM Sales.Orders WHERE OrderNo LIKE '[^0-9]%';

-- 转义自带的方括号字符
SELECT * FROM Sales.Orders WHERE OrderNo LIKE '%[[]%' ESCAPE '\';

连ESCAPE转义的细节都考虑到了。一个LIKE尚且如此，其他语法点做到什么程度，可以想见。

七、代码不用改，迁移工具把剩下的活包了

语法兼容解决了"代码能不能跑"，数据搬运和对象转换这环节，金仓的迁移工具KDMS负责。它的流程分评估、迁移、校验三段：评估阶段先扫源库，给出对象兼容性分析和改造工作量预估，让项目组在动手之前就知道哪里有坑；迁移阶段自动完成表结构转换、数据搬迁和应用对象（存储过程、函数、触发器、视图）的转换；校验阶段做数据比对，行数、校验值逐表核对，保证搬过去的数据一条不差。

对SQL Server这条迁移路线，评估报告能把不兼容对象逐条列出来。实际项目里大多数系统评估下来是"基本无改造或少量改造"的结果，剩下零星几个点，改起来也有明确清单，不是摸着石头过河。

八、一个真实的例子：省级环保集团的"极简"迁移

某省级环保集团的信息系统原库是SQL Server，库里有几百个存储过程和函数，涉及在线监测、统计分析多个业务模块。按项目组最初估算，仅存储过程改造一项就要投入数月人力，赶上业务旺季根本排不开窗口。

实际操作下来，这套系统迁到KES V9R4C019的过程被项目组形容为"极简"：KDMS评估显示绝大多数对象直接兼容，存量T-SQL代码原样运行，MERGE、OUTPUT、窗口函数这些高频特性都在正常干活，存储过程基本没有动逻辑，开发团队只处理了个别边缘场景。整个迁移周期比原计划大幅缩短，业务系统切换当天平稳过渡，没有出现报表数字对不上的情况。

这个案例最有说服力的地方在于：环保监测这类系统的SQL复杂度不算低，统计口径繁多，如果兼容性有短板，一定会在某个报表上暴露出来。而它顺顺利利跑起来了，说明兼容不是停留在语法手册的层面。

写在最后

回到开头那个问题：SQL Server数据库迁移，到底难在哪？难在十几年的存量代码、难在没人说得清哪条SQL里埋着业务规则。靠人肉改写，成本和风险都不可控。

金仓KES V9R4C019的做法是把兼容做深做细——MERGE、并行DML、OUTPUT子句、窗口函数、PIVOT/UNPIVOT这些T-SQL核心特性补齐，LIKE通配符这类细节也不放过，配合KDMS把评估、迁移、校验的流程工具化。对开发团队来说，最直观的变化就是：原来准备好的数月改造计划，最后变成了"跑通验证、按期切换"。

国产化替代走到今天，拼的早已不是"能不能替代"，而是"替代的代价有多小"。从这个角度看，"存量代码零修改、极少修改"这八个字，可能比任何性能指标都更接近用户真正关心的问题。