不能直接“平滑迁移”，旧版存储过程在高版本中虽多数能运行，但必须验证兼容性级别、语法弃用和执行计划变化，否则上线后可能突然变慢或报错。

不能直接“平滑迁移”——旧版存储过程在高版本中多数能运行，但必须验证兼容性级别、语法弃用和执行计划变化，否则上线后可能突然变慢或报错。

检查并设置数据库兼容性级别

SQL Server 不会自动升级数据库的 COMPATIBILITY_LEVEL，即使你把 SQL Server 2016 的数据库还原到 SQL Server 2025，默认仍是 130（对应 2016）。这会导致新优化器不启用，也可能掩盖潜在问题。

• 查当前级别：SELECT compatibility_level FROM sys.databases WHERE name = 'YourDB';
• 设为最新（如 SQL Server 2025 对应 170）：ALTER DATABASE YourDB SET COMPATIBILITY_LEVEL = 170;
• 注意：改完不会立即重编译所有存储过程，首次执行时才按新 CE（基数估计器）生成计划，可能引发性能抖动
• 建议先在测试库改级别 + 手动执行 EXEC sp_recompile 'YourProcName';，观察执行计划是否合理

识别并替换已弃用的 T-SQL 语法

SQL Server 2022/2025 明确移除了部分旧语法，比如 sp_addextendedproc、SET ROWCOUNT 在 INSERT/UPDATE/DELETE 中的全局影响、RAISERROR 的旧式参数格式等。这些在低版本中能跑，高版本可能直接报错。

• 用 SSMS 的“查询分析器” → “包含执行计划”执行存储过程，留意警告图标（黄色感叹号）
• 重点扫描：SELECT * FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) t WHERE t.text LIKE '%RAISERROR%' OR t.text LIKE '%SET ROWCOUNT%'
• 替换成 THROW（推荐）或带 5 参数的 RAISERROR(..., 16, 1)
• 避免用 SELECT * 在临时表定义中，高版本对列名推断更严格，易导致后续 INSERT 失败

处理孤立用户与权限继承问题

备份还原后，sys.database_principals 里的用户可能仍指向旧服务器的 SID，造成“登录名存在但无法访问存储过程”，尤其当过程里用了 EXECUTE AS 或跨库查询时。

• 查孤立用户：EXEC sp_change_users_login 'Report';（SQL Server 2022+ 已弃用，改用 ALTER USER ... WITH LOGIN = ...）
• 修复映射：ALTER USER [MyUser] WITH LOGIN = [MyLogin];
• 若过程内调用 INSERT INTO linked_server...，需确认链接服务器登录映射是否重建（sp_addlinkedsrvlogin 需重配）
• 注意：SQL Server 2022 开始，guest 用户默认被禁用，若旧过程依赖它，需显式启用或改权限模型

验证执行计划回归与参数嗅探风险

升级后最隐蔽的问题不是报错，而是某条关键存储过程从 200ms 慢到 8s——通常因新基数估计器（CE）对参数值敏感，或统计信息未更新。

• 启用查询存储：ALTER DATABASE YourDB SET QUERY_STORE = ON;，再执行几次不同参数的调用
• 对比旧/新版本中同一语句的计划哈希：SELECT query_id, plan_id, avg_duration FROM sys.query_store_runtime_stats WHERE query_id IN (SELECT query_id FROM sys.query_store_plan WHERE plan_id = @old_plan_id);
• 若发现计划突变，可用 OPTION (USE HINT('DISABLE_PARAMETER_SNIFFING')) 临时缓解，但根治要靠更新统计信息或重写 WHERE 条件
• 不要忽略 tempdb 文件配置：高版本默认启用 TF 1118，若旧环境是单文件 + 自动增长，上线后可能因 PFS 争用卡住存储过程

真正麻烦的从来不是“能不能跑”，而是“为什么这次跑得慢”——尤其是那些没加事务、没设超时、依赖旧 CE 行为的存储过程，上线后第一个高峰就暴露。务必在目标版本上用真实数据量压测，而不是只看语法通过。