SQL Server 里存储过程改完却像“没改一样”，问题通常不在语句本身，而在执行计划缓存没有及时刷新。

说白了，ALTER PROCEDURE 并不会主动把旧计划清掉。SQL Server 还可能继续复用缓存里的旧逻辑，所以修改看起来就没有真正落地。

要让变更生效，通常需要手动执行 DBCC FREEPROCCACHE 或 sp_recompile。

SQL Server 存储过程修改后没生效，大概率不是代码写错了，而是执行计划缓存没刷新。

ALTER PROCEDURE 不会自动清掉旧计划，SQL Server 仍复用缓存里的老逻辑。

为什么 ALTER PROCEDURE 后调用还是旧结果

SQL Server 在把存储过程编译完成之后，会把对应的执行计划放进 sys.dm_exec_cached_plans 缓存里。

后面无论是用 CALL 还是 EXEC 去执行，通常都会直接复用这份计划。即便源码已经通过 ALTER PROCEDURE 改过了，也不代表会立刻切到新逻辑。

只要这份缓存计划还没被清掉，就会一直沿着原来的执行路径跑。

• 验证方法：查 sys.dm_exec_procedure_stats，对比 last_execution_time 和你修改时间，若明显滞后，说明在跑旧计划
• 典型现象：CALL 返回结果、影响行数、甚至报错信息都和修改前一致
• 参数或统计信息没变时，优化器更倾向“偷懒”复用，不会主动重编译

DBCC FREEPROCCACHE 清什么、不清什么

DBCC FREEPROCCACHE 只清执行计划缓存，也就是编译后的查询计划。

它不碰数据页，不删统计信息，也不重置 sys.dm_exec_procedure_stats 里的执行计数。

• 清全部：直接运行 DBCC FREEPROCCACHE，影响所有数据库所有缓存计划——生产环境慎用
• 清单个：先从 sys.dm_exec_cached_plans 查出目标 plan_handle，再执行 DBCC FREEPROCCACHE (plan_handle)
• 别误用 DBCC FREESYSTEMCACHE ('ALL')：它清得更广（含资源池、元数据等），副作用不可控

比 DBCC 更温和的替代方案

优先用 sp_recompile 标记存储过程为“需重编译”。这样会在下次调用时才真正编译，对性能冲击小得多。

• 执行 EXEC sp_recompile 'your_procedure_name' 即可
• 它只更新 sys.objects 的 is_ms_shipped 和相关标志位，不强制刷缓存
• 适合生产环境日常维护，尤其当你不确定是否所有调用方都已重启连接时
• 注意：对 Azure SQL Database 和 SQL Server 2016+ 有效；旧版本需确认兼容性

容易被忽略的跨版本/跨平台细节

不同环境处理方式差异大，硬套同一套流程容易踩坑。

• MySQL 不支持 ALTER PROCEDURE 刷新逻辑，必须 DROP PROCEDURE + CREATE PROCEDURE 才生效
• Azure SQL Database 和 SQL Server 2016+ 支持 WITH NO_INFOMSGS 抑制 DBCC FREEPROCCACHE 输出，旧版本会报错
• sql_handle 在 sys.dm_exec_query_stats 中对应的是语句级缓存项，不是整个存储过程——想精准清除一个 SP 的所有计划，得靠 plan_handle 或 pool_name（如果启用了 Resource Governor）
• ORM 框架（如 Entity Framework）可能缓存了存储过程元数据，改完 SP 后不重启 AppDomain 或不清 SqlCacheDependency，照样返回旧结果

最稳妥的处理闭环

最稳妥的闭环动作永远是：改完 ALTER PROCEDURE 后，先查 sys.dm_exec_cached_plans 确认旧计划是否还在。

如果旧计划还在，就手动清除或标记重编译，然后再验证结果。

别依赖“改完就生效”的直觉。这在 SQL Server 里从来不是默认行为。

《夸克》非常好用的免费AI浏览器

下载APP查看