平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“SQL Server 数据库迁移并非只改连接串：KES 兼容回归清单”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

在这个场景下，SQL Server 数据库迁移的项目里，最容易被低估的一个问题是什么？其实就是“原来的 SQL，还能不能按原来的方式继续工作”。表结构和数据这些，借助工具是能搬过去的。但应用这边呢，往往会在存储过程、报表查询、批处理脚本里用了一堆 T-SQL 的特性。那么迁移团队如果只是做一次连接测试就完事的话，很可能要到上线之后的某条分支逻辑里，才碰到语法或者结果上的差异，这时候就麻烦了。

在这个场景下，我个人更倾向的做法是，把兼容性验证当成一份回归清单来做。金仓 KES V9R4C019 对 SQL Server 常用的 MERGE、同时行 DML、OUTPUT、窗口函数、PIVOT/UNPIVOT 还有 LIKE 通配符这些能力，都做了补齐或者增强。意义在于什么呢？就是让存量的代码尽可能保留下来。但是注意，“尽可能保留”这件事，必须借助结果集、事务和并发行为去验证，不能光看语句执行成功了就认为没问题。

从代码资产开始盘点

理解这一步时，第一点的时候，不要急着去改 SQL。先把代码来源分清楚：数据库里面的视图、函数、存储过程和触发器，算是一类；应用仓库里的 Mapper XML、脚本文件和 ORM 模板，这是另一类；还有运行时拼接出来的 SQL，又是第三类。

落到代码里，我会给每一条语句都附上来源模块、调用接口和业务优先级。这么做的好处是什么呢？就是出现不兼容的情况时，能够先处理交易链路，低频报表往后放一放。KDMS 是能帮你采集对象和应用 SQL 的，不过采集出来的结果，还是要和代码仓库、线上日志互相核对一下。为什么？就是为了避免把没采集到的动态语句误判成不存在，这种事其实挺常用的。

MERGE 要验证的不只是语法

MERGE 这个语句，通常用在同步主数据或者批量 upsert 的场景。SQL Server 的代码呢，可能会依赖匹配、未匹配和删除分支的组合：

MERGE INTO dbo.product AS t
USING @incoming AS s
   ON t.product_id = s.product_id
WHEN MATCHED AND s.disabled = 1 THEN
  DELETE
WHEN MATCHED THEN
  UPDATE SET product_name = s.product_name,
             price = s.price
WHEN NOT MATCHED THEN
  INSERT (product_id, product_name, price)
  VALUES (s.product_id, s.product_name, s.price);

在这个场景下，迁移回归的话，至少要覆盖四个场景：匹配更新的情况、未匹配插入的情况、条件删除的情况，还有源数据出现重复键的情况。另外还要观察一下，同一个事务里面触发器有没有执行、受影响行数是怎么得到的、发生冲突之后回滚是不是回得完整。KES 是兼容 MERGE 的，这样就能减少把一条语句拆成好几段分支的改造工作。但是话说回来，最后还是要按业务数据来验证，这一步省不掉。

OUTPUT 会影响应用下一步动作

很多应用会用 OUTPUT 去拿生成键，或者拿到记录变更前后的值。那么迁移之后呢，就算插入是成功的，如果得到的列顺序、类型或者空值行为变了，应用在下一步组装请求的时候就可能出错。这种问题往往很隐蔽，不容易第一时间发现。

DECLARE @new_rows TABLE (id bigint, created_at datetime2);
INSERT INTO dbo.invoice(customer_id, total_amount)
OUTPUT inserted.invoice_id, inserted.created_at
INTO @new_rows(id, created_at)
VALUES (@customer_id, @amount);
SELECT id, created_at FROM @new_rows;

理解这一步时，我的习惯是，成功路径和失败路径要同时测。例如，唯一键冲突的时候还返不得到记录？事务回滚之后，临时表是不是空的？批量插入的时候，得到顺序应用那边能不能接受？这些问题，只跑一条成功样例是覆盖不到的。

窗口函数要对齐边界条件

实际处理时，窗口函数一般出现在分页、排名，还有“每组取最新一条”这种查询里。ROW_NUMBER、RANK、LAG 还有累计聚合，看起来仅仅是函数名不一样而已。但实际上呢，结果还会受排序稳定性、NULL 排序位置和窗口框架的影响。

WITH ranked AS (
  SELECT employee_id,
         department_id,
         salary,
         ROW_NUMBER() OVER (
           PARTITION BY department_id
           ORDER BY salary DESC, employee_id
         ) AS rn
  FROM employee
)
SELECT employee_id, department_id, salary
FROM ranked
WHERE rn <= 3;

结合项目来看，那测试数据怎么准备呢？要包含工资同时列的情况、有空值的情况、只有一条记录的部门，还有没有任何匹配记录的部门。KES 的兼容兼容，让原来的 SQL 有机会直接跑起来。不过排序和分页的边界，仍然要跟旧系统一行一行去对照，这个工作量省不得。

PIVOT/UNPIVOT 关系到报表列

实际处理时，财务和运营的报表，经常会把月份转成列来展示。用了 PIVOT 的原 SQL 迁移之后，如果列名、空月份还有数值精度的处理方式不一样了，报表导出就会出现一种情况——“列还在，但数字不对了”。这个对业务方来说其实挺头疼的。

SELECT account_id, [2025-01], [2025-02], [2025-03]
FROM (
  SELECT account_id, month_key, amount
  FROM account_monthly
) s
PIVOT (
  SUM(amount) FOR month_key IN ([2025-01], [2025-02], [2025-03])
) p;

实际处理时，回归的时候呢，要把缺失月份、重复月份、金额为 NULL 的记录都包含进去。UNPIVOT 这边呢，要检查一下空值行有没有保留。KES 对这两类语句的兼容，好处在于让报表逻辑先保持原貌跑起来，性能的事能够后面再决定要不要改写。

并行 DML 需观察资源曲线

从实现思路看，批量清理和月末结算这种场景，可能会依赖同时行 DML。那迁移的时候最危险的误区是什么呢？就是看到 SQL 能跑了，直接把并行度开到最大。为什么要小心呢？因为并行执行是要消耗 CPU、内存、日志还有临时空间的。在线业务高峰期的话，还可能让锁等待变多。

在这个场景下，我的做法是，把同时行回归分成低、中、高三个档位，分别记录总耗时、受影响行数、锁等待、日志增长还有业务接口的延迟。需留意一点，单次批处理变快了，不代表整个平台就更快了。如果报表查询和在线交易同时都变慢了，那就说明参数没调对，得回头重新来。

LIKE 是兼容性最细的检查点

动态搜索通常都是写成 LIKE 的。但是通配符、转义、排序规则，还有大小写敏感性，这些都有可能改变结果。尤其是应用允许用户自己输入 % 或者 _ 的情况，必须确认转义字符前后是一致的，不然很容易出问题。

SELECT product_id, product_name
FROM product
WHERE product_name LIKE @keyword ESCAPE '\';

结合项目来看，回归数据这边呢，应该把中文、大小写字母、百分号、下划线、反斜杠还有空字符串都放进去测一遍。另外还要检查一下参数类型到底是 varchar 还是 nvarchar。为什么这个重要呢？因为字符集和隐式转换的问题，可能带来索引失效，或者结果发生变化。KES 对通配符细节的兼容，价值其实就在这里——把那些“小地方”的额外改造给省下来。

连接和事务不能被兼容语法遮住

在这个场景下，应用代码几乎不改，不等于连接层不改。JDBC 驱动、连接 URL、默认 schema、认证方式、连接池重连和超时参数都要单独验证。迁移后常用的问题是：开发环境能连，连接池在网络闪断后无法恢复；查询能执行，批量提交时却因为事务隔离级别不同而出现锁等待。

从实现思路看，我会把连接回归放在真实连接池中做，至少覆盖首次连接、空闲连接复用、数据库重启后的重连和事务异常回收。对于依赖 SQL Server 系统表、作业代理、CLR 或 Service Broker 的能力，也要单列为人工改造项。

数据类型要做“往返测试”

落到代码里，SQL 语法兼容之后，还有一类问题不一定马上报错，那就是数据类型映射。金额字段的精度和标度、datetime2 的小数秒、uniqueidentifier、大文本、二进制数据以及 nvarchar，都可能在写入和读回时产生边界差异。只检查建表成功，会漏掉应用实际绑定参数后的行为。

我会准备一组边界值：最大和最小金额、超过日常长度的中文字符串、毫秒和微秒时间、空字符串、NULL、大对象以及特殊字符。数据从应用写入 KES 后再读回，同时与原输入逐字段比较，这就是“往返测试”。如果系统还处于双轨期，也能够让同一组请求分别进入旧库和新库，再比较接口响应，而不是直接比较数据库内部显示格式。

在这个场景下，默认值也值得单独检查。应用有时省略某个字段，依赖数据库自动生成时间、流水号或状态；迁移后如果默认表达式不同，INSERT 本身仍会成功，业务数据却会慢慢分叉。触发器、序列和自增列应和数据类型一起列入回归清单。

错误路径要比成功路径多测一步

实际处理时，迁移验证常把主要精力放在成功交易上，错误处理却决定了系统出问题时会不会重复扣款或重复下单。需主动制造唯一键冲突、外键失败、超时、死锁和连接中断，观察应用是否得到可识别的错误，事务是否完整回滚，连接是否还能放回池中继续采用。

从实现思路看，SQL Server 与 KES 的错误码和异常文本不必完全相同，应用却不能依赖一段固定中文报错做业务判断。更稳妥的方式是由数据访问层把数据库异常归类，再向上层得到稳定的业务错误。迁移盘点发现这类耦合时，应把它列为应用改造，而不是用数据库兼容性把问题盖住。

理解这一步时，批处理还要验证部分失败。假设一次提交 1000 条记录，其中一条违反约束，应用预期是整批回滚还是跳过错误行继续？这个行为需由业务规则决定，同时在新库上重复验证。它对数据一致性的影响，通常比一条查询快几十毫秒更大。

一套可执行的迁移顺序

项目实施能够按以下顺序推进：

1. 采集并分类 SQL Server 对象和应用 SQL；
2. 在 KES 上完成结构构建和静态兼容检查；
3. 先回归 MERGE、OUTPUT、窗口函数、PIVOT/UNPIVOT、LIKE 等高频特性；
4. 再验证连接池、事务、批处理和并发资源；
5. 用双轨或灰度方式对照关键接口结果；
6. 关闭问题清单后再安排切换。

从实现思路看，这个顺序的好处是先确定“语句语义能否保留”，再处理“上线后是否稳定”。如果一开始就同时改 SQL、换驱动、调同时行参数，出了问题很难知道是哪一层造成的。

理解这一步时，执行过程中能够维护一张回归矩阵，每个用例记录源端结果、KES 结果、差异原因、处理方式和复测状态。核心交易必须逐项关闭，低频功能能够按风险安排灰度。矩阵比一句“兼容性测试借助”更有用，因为后续版本升级时能够再次运行，而不用重新回忆当时测过什么。

结语

结合项目来看，SQL Server数据库迁移的目标，不是机械地保证每条语句都不变，而是把真正需改的地方缩小到可管理的范围。KES V9R4C019 对常用 T-SQL 特性的兼容，为存量应用保留了较大的迁移空间；KDMS 的评估和对象采集，则帮助团队在改造前看见风险。

实际处理时，我会把“结果集、事务边界、同时发资源、连接”作为四道验收门。四道门都借助，才有资格说这次迁移接近零修改；只做语法借助测试，最多只能说明数据库接受了这条 SQL。