T-SQL批处理迁移新平台的兼容性评估与改造实战指南

1. 迁移前夜：先给存量 T-SQL 批处理做一次“体检”

很多团队在接到数据库迁移任务时，第一反应是“把备份恢复过去，改个连接串就完事”。这个思路放在纯 OLTP 的小系统上可能够用，但一旦背上多年的 T-SQL 批处理，尤其是那种几百行起步、带着游标、临时表、动态 SQL 混着来的“祖传脚本”，新环境分分钟教你做人。V9R4C019 这类新平台在兼容旧代码的思路上做了大量调整，但它的优化器行为、数据类型处理、废弃功能移除策略都和老版本有明显差异，你如果不提前摸底，迁移后的第一个月末结算就可能变成通宵排障现场。

这一节我先带着你把“体检”这件事做扎实。记住一个原则：迁移不是把数据搬过去，而是把整个运行生态搬过去，T-SQL 批处理就是这个生态里的“老员工”，你至少得知道他平时干活用什么姿势、有哪些坏习惯。

1.1 兼容性级别是第一道坎

T-SQL 的行为差异，第一来源就是数据库的兼容性级别。

V9R4C019 默认会支持一个较新的兼容性级别，而很多存量系统还停留在 2008 R2 或 2012 时代的级别上。兼容性级别决定着解析器如何理解你的 SQL、优化器用哪套基数估计模型、某些函数返回什么格式。举例来说，从旧级别切到新级别，最典型的差异是基数估计（Cardinality Estimation）从 legacy CE 切到新版 CE，很多原本“跑得还行”的查询会因为行数估算变化，执行计划彻底重排，批处理的整体耗时就变了。

查看当前库的兼容性级别很简单：

如果发现还在 100 或 110 这种老级别，注意：虽然 V9R4C019 为了兼容可以让库保持老级别运行，但这不是长久之计。老级别意味着你用不上新的优化器改进，而且部分新特性（比如一些新的内置函数、索引结构）在老级别下会报错或者表现异常。我的建议是：先评估，再升级。评估的标准是——你的批处理里有多少语句依赖老版本的“隐性行为”。

举个例子，旧版本里 SELECT * INTO #tmp FROM ... 这种建临时表的方式，在并发场景下锁行为比较粗糙，新版本会采用更精细的锁粒度。看起来是性能提升，但如果你的批处理在一个长事务里反复创建和删除临时表，锁粒度变化可能导致死锁的触发时机不一样了。这个属于“行为差异”，不跑回归测试根本发现不了。

提示：迁移初期可以先把兼容性级别保持成迁移前的级别，跑通业务后再逐个库升级到最新级别。这不是妥协，而是给排查留出隔离变量。

1.2 废弃功能与“修改过的行为”清单

V9R4C019 在底层引擎上做了大量翻新，因此服务端会主动标记一批废弃功能。凡是用了这些功能的批处理，不是“变慢”而是“直接报错”。

常见雷区包括：

• 旧式 *= 和 =* 外连接语法，这个 2012 之后就废了，老脚本如果还在用，迁移后直接语法错误。
• WRITETEXT / READTEXT 操作 text / ntext 字段，新版虽然还保留接口但已经不建议，更麻烦的是与新版数据类型结合时行为怪异，建议改成 UPDATE ... SET 列 = ... 或 Value 函数。
• COMPUTE BY 子句，老版本用于生成分组小计，新版本已移除，必须改成 ROLLUP 或 GROUPING SETS。
• sp_dboption 这类系统存储过程，直接不存在了。
• RAISERROR 的旧式写法（RAISERROR 50001 'msg'）虽然还能跑，但推荐的 THROW 有完全不同的错误严重级别处理方式，两者对批处理中事务提交回滚的行为影响不同。

这些也不是背清单就能防住，更靠谱的办法是上工具。用数据库迁移助手（Database Migration Assistant）跑一遍静态扫描，它能识别出大部分兼容性问题，并标注影响级别。这个工具免费，扫描完后会生成一份报告，包含问题对象名称、所在存储过程或批处理路径、建议修复方案。实际用下来准确率还算可以，至少能帮你省掉一轮人工翻代码的时间。

1.3 排序规则与元数据差异

排序规则（Collation）是另一个容易被忽视的坑。两个数据库实例的默认排序规则不同，会导致字符串比较的结果不同。比如老库用的是 Chinese_PRC_CI_AS，新库默认可能是 Latin1_General_CI_AS，表面上中文能存，但排序、比较、甚至索引查找的结果都不一样，批处理里那些 WHERE 姓名 = '张三' 的条件就可能在执行计划里走全表扫描。

另一个元数据差异是系统视图的变化。老脚本里经常能看到 sysobjects、sysindexes 这种兼容视图，V9R4C019 里依然保留着，但它们只是兼容性外壳。如果你在批处理里用了 sysprocesses 查会话状态，新版本里最好改成 sys.dm_exec_sessions 和 sys.dm_exec_requests，否则有些列已经拿不到准确的值了。

实操上，我先建一张“批处理清单表”，把线上所有作业、存储过程、定时任务关联的 T-SQL 都登记进去，然后逐条确认：

1. 是否依赖特定排序规则下的字符串行为；
2. 是否引用旧系统表；
3. 是否有 tempdb 使用习惯（老系统喜欢把临时表建在业务库里）。

这张清单做完，迁移方案的雏形就出来了。

2. 存量 T-SQL 批处理的改造思路，别急着动手改代码

体检报告出来之后，你面对的可能是一堆“问题列表”，但别急着逐条改。先明确优先级：能通过数据库配置兼容的先配置，能通过会话选项兼容的先会话，最后才是改代码。 这个顺序能够降低改造范围，减少回归风险。

2.1 三个开关：兼容性级别、数据库作用域配置、查询存储

对于不需要改代码就能兼容的问题，V9R4C019 提供了几个“开关”。

第一个是兼容性级别本身。前面说过，如果批处理里大量使用旧式行为，短期内保持旧级别是最稳妥的。这里补充一个细节：新版本允许在“数据库级别”设置兼容性级别，不用影响整个实例，所以你可以做到“实例新、库旧”，业务侧无感知。

第二个是数据库作用域配置。比如 LEGACY_CARDINALITY_ESTIMATION = ON 可以让整个库使用旧版基数估计器，这适合那种“优化器一换就崩”的场景。我遇到过一条 50 行左右的批处理，核心是一条 6 表关联的汇总查询，在旧库上 2 秒跑完，迁到新库变 40 秒，开了这个开关之后恢复原状。

第三个是查询存储（Query Store）。这是我在所有迁移项目里都会强制打开的配置。它能够记录每条查询的执行计划、运行时统计、等待统计，还能强制执行计划。对于存量批处理，你不需要靠猜来定位哪条语句跑偏了，直接查看 Query Store 的 Top Resource Consuming Queries 就能看到迁移前后的差异。

注意：Query Store 本身也会有性能开销，对于写入密集型的 OLTP 系统建议设置 Data Flush Interval 和 Stale Query Threshold，避免无限制累积。

2.2 高风险 T-SQL 模式的重构三板斧

碰到非改不可的代码，最常见的三类高风险模式需要重点处理：游标、动态 SQL、临时表/表变量混用。

游标是批处理性能的头号杀手。老系统里的“循环逐行处理”逻辑，在新版的集合操作优势下几乎总是被建议推翻。我改造的典型案例是一个对账批处理，原本用游标遍历十万行欠费记录，逐行去查关联表，跑完需要 40 分钟。改成基于集合的 UPDATE ... FROM 关联更新后，耗时降到 3 分钟。注意不是所有游标都能改，那种“逐行调用存储过程”的确实难办，但大部分游标本质上是“逐行查询+累加汇总”，这种就可以改写为窗口函数或派生表。

动态 SQL的问题在于：拼接出来的字符串无法被优化器提前解析，执行计划缓存效率低，而且容易受参数值影响走偏。如果批处理里必须用动态 SQL，我的建议是：

• 优先改造成 sp_executesql 并传入参数，让查询参数化；
• 如果无法参数化，至少把动态 SQL 的作用范围限定在几类已知的模式里；
• 绝不在动态 SQL 里拼接用户输入，这个既是性能问题更是安全问题。

临时表和表变量的选择也有讲究。很多老批处理习惯用 #临时表 存储中间结果，但忽略了统计信息的维护。新版里临时表依然会维护统计信息，但如果你大批量插入后直接关联查询，统计信息可能过期。建议在批量插入后显式 UPDATE STATISTICS，或者将中间结果放入带主键的表变量并让优化器能看到行数预估。

2.3 顺序执行与并发控制的兼容策略

存量的批处理里有不少是“一个作业调用一串存储过程”，过程中有显式事务和锁。这块在迁移后出问题通常不是语法错误，而是并发行为改变。比如老版本默认使用 READ COMMITTED 且锁粒度较粗，批处理在长事务里持锁时间挺长，但并发系统也习惯了；新版本在快照隔离上的能力更强，但如果你没开启 READ_COMMITTED_SNAPSHOT，写冲突的报错信息可能变了。

我的经验是：在批处理改造时不要盲目添加 WITH (NOLOCK) 或降低隔离级别。 表面看查询快了，但一致性风险被你自己的双手放大了。更合理的做法是评估每个批处理的事务边界，能缩短事务的尽量缩短，不能缩短的明确隔离级别，并把这些信息登记在批处理清单里，方便后期查问题。

3. 实操迁移全过程：从备份恢复到批处理回归

这一节我按实际操作的顺序，把 V9R4C019 上迁移存量库并验证 T-SQL 批处理的完整流程拆开讲。这里我以最常见的“备份恢复”方式为例，虽然方法传统，但可控性最强。

3.1 迁移方式选型：备份恢复、分离附加、还是日志传送

先说选型逻辑。四种常见方式对比：

绝大多数情况下我推荐备份恢复。它不需要源库停机太久，只要在备份那一刻保证一致性，后面恢复出来就是一份完整的库。V9R4C019 对这一流程支持得很流畅，含内存优化表的库恢复也不会有坑。

3.2 一次完整的备份恢复迁移步骤

以下是我在实际项目中反复验证过的流程：

1. 源库做全量备份，最好选择业务低谷期。

2. 拷贝备份文件到目标服务器，拷贝过程中校验文件大小和 MD5，避免网络传输导致损坏。

3. 目标实例上恢复数据库：

注意 WITH MOVE 这一步尤其关键。很多新手恢复时报“文件已存在”或路径无效，就是因为没指定逻辑文件名对应的物理路径。建议恢复前先执行：

看到逻辑名列表后再写 MOVE 子句。

4. 恢复后立即处理孤立用户。数据库里有数据库用户，但目标实例的登录名里没有对应的 SQL Server 登录，这时候应用连接会报“用户登录失败”。处理方法是：

如果是老系统里大量账号需要映射，可以用 sp_change_users_login 的替代方案：

这个存储过程在新版本里虽然标记为弃用但还能用，贴一下是为了照顾老项目。

5. 检查数据库属性：确认目标库的兼容性级别、恢复模式、排序规则是否符合预期。这一步不可跳过，尤其是恢复模式，很多生产库是 FULL，恢复到新环境后日志增长快，容易把磁盘塞爆。

3.3 批处理回归测试的方法论

数据恢复完成之后，正式业务切换之前，必须做一轮针对 T-SQL 批处理的回归验证。这个环节最怕“凭感觉”，我自己整理了一套可以照抄的方法。

第一步：搭建对比基线。 在迁移前的旧环境上，找业务低谷窗口，用 SQL Profiler 或扩展事件抓取批处理相关的语句。具体抓什么：RPC:Completed 和 SQL:BatchCompleted 事件，保存执行耗时、逻辑读写、CPU 时间。这套数据就是你的“老朋友平时干活的速度”。

第二步：在新环境上重放。 不需要完整的压力测试工具，如果批处理是定时任务触发的，直接在 SQL Agent 里把作业手动跑一遍。如果批处理由外部应用调用，那就用应用侧的交易号触发一次。

第三步：对比执行计划。 重点查看两条同类语句的执行计划中，是否有表扫描/索引扫描变多、预估行数与实际行数偏差、连接类型从 Hash Match 变成 Nested Loop 等变化。Query Store 可以帮你把计划找出来。

第四步：核对结果数据。 批处理迁移后最隐蔽的风险是“没报错，但结果错了”。比如旧库的日期处理逻辑在不同兼容级别下返回格式不同，汇总结果一致但精度差了小数点。建议每个批处理都设计一个“输出比对”环节，比对迁移前后跑出的结果集。

4. 常见问题与排查技巧实录

这一节我直接整理实战中反复踩过的坑，每条都是真实遇到过的，对应给出排查命令和解决思路。

4.1 典型报错与处理速查表

4.2 性能退化排查：从等待统计开始

批处理迁移后常见的现象是“能跑通，但变慢了”。我的排查顺序是：

先查等待类型，用这条语句看当前或历史会话的等待：

如果看到 PAGEIOLATCH_* 变多，说明磁盘 IO 是瓶颈，可能是新环境的数据文件分布在存储性能较差的磁盘上。看到 LCK_M_* 变多，则说明锁等待增加了，需要检查事务隔离级别或长事务。

然后对比 Query Store 里的执行计划。重点看是否有“计划回归”（plan regression），即同一语句在迁移后选择了不同的执行计划。解决方案有两个：一是用 Query Store 强制执行旧计划；二是更新统计信息后让优化器重新评估。

注意：DBCC FREEPROCCACHE 会清空整个实例的计划缓存，生产环境慎用。推荐在维护窗口执行，或只针对特定数据库使用 ALTER DATABASE ... SET PARAMETERIZATION FORCED 缓解参数嗅探问题。

4.3 独门避坑经验：时间函数与隐式转换

存量 T-SQL 批处理里最容易“悄悄出错”的是时间处理。不同版本 GETDATE()、SYSDATETIME() 的精度不同；字符串转日期时，如果语言设置不同，'2024-01-05' 可能被解析成 1 月 5 日也可能 5 月 1 日。我踩过一次大坑：一套月末结算批处理在迁移后连续三天报“数据对不上”，最终定位到CONVERT(datetime, '2024-05-01') 在目标库被解析成 5 月 1 日，而源库因为默认语言是 us_english 被解析成 1 月 5 日。

解决方式是在批处理里统一采用显式格式：

另一个高频问题就是隐式转换。VARCHAR 和 NVARCHAR 比较时，如果列类型不一致，会导致索引失效。最典型的就是表设计时用了 VARCHAR，但批处理参数传入的是 NVARCHAR，迁移后优化器可能选择全表扫描。

解决办法：给存储过程参数定义和表列保持一致的数据类型，不要图省事全用 NVARCHAR(MAX) 兜底。这一点在批处理代码审查时就要纳入检查清单。

4.4 最后的兜底：批处理失败后的快速回退

即使准备做了很多，也要想好回退方案。我的习惯是：在目标环境建立之后，保留源环境 2 到 4 周，同时维护一份“可回退脚本清单”。清单内容包括：

• 源库存放的原始备份文件位置；
• 恢复时用到的 MOVE 路径；
• 一键回切业务连接的说明（改连接串或 DNS 指向）；
• 增量数据补偿方案（比如自迁移时间点后，源库产生的业务单据如何补录）。

有了这份预案，批处理在验收阶段出大问题时，你可以很从容地选择回退，而不是在生产环境上硬扛着调试。

5. 写在最后：迁移的真正难点是人处理“老代码”的耐心

数据库迁移这个活，表面上考验的是命令熟不熟练，实际上考验的是你面对“不能跑、不敢改、改不起”的存量代码时，有没有一套系统的方法论。V9R4C019 在引擎能力上确实比老版本上了一个台阶，但它不是魔法，不能自动把你的游标改成交集操作、不能把你的隐式转换问题消除，它只是给了你更多工具和更清晰的问题指示器。

我个人整理了三个坚持了很久的习惯，最后分享给读者。

第一，每次迁移都必须做“源环境性能快照”。别等到出了问题再回去比较，那时候源环境可能已经不在线了。

第二，存量批处理的改造宁可慢一点，也要保持“每次只改一类风险”的节奏。把所有改动混在一起做，出了问题你连定位都没法定位。

第三，把批处理清单、兼容性评估报告、回归测试记录整理成文档，不只给自己看，也给后来接手的同事看。数据库迁移是一次性的，但这些文档的价值会持续很多年。

如果你正好在准备类似的迁移，希望这篇文章能帮你少踩几个坑。数据无价，回退有路，迁移这件事，仔细永远不亏。