不能直接“平滑迁移”，旧版存储过程在高版本中虽多数能运行，但必须验证兼容性级别、语法弃用和执行计划变化，否则上线后可能突然变慢或报错。
不能直接“平滑迁移”——旧版存储过程在高版本中多数能运行，但必须验证兼容性级别、语法弃用和执行计划变化，否则上线后可能突然变慢或报错。
检查并设置数据库兼容性级别
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 行为的存储过程，上线后第一个高峰就暴露。务必在目标版本上用真实数据量压测，而不是只看语法通过。
