ALTER PROCEDURE 不会清除执行计划缓存，需用 sp_recompile 标记重编译或通过 plan_handle 精准清除；直接 DBCC FREEPROCCACHE 风险高，生产环境应避免。

改完存储过程立刻执行，结果还是老样子——不是代码没改对，而是 SQL Server 正在复用缓存里的旧执行计划。

ALTER PROCEDURE 不会自动清缓存

SQL Server 编译并缓存存储过程的执行计划，后续调用默认复用。即使你用 ALTER PROCEDURE 更新了逻辑，只要原 plan_handle 还在 sys.dm_exec_cached_plans 里，就继续走旧路径。

• 验证方法：查 sys.dm_exec_procedure_stats，对比 last_execution_time 和你修改的时间，若明显滞后，说明缓存没刷新
• 常见现象：执行后返回数据、字段、甚至错误提示都和修改前一致，但 SELECT * FROM sys.procedures 显示 modify_date 已更新
• ALTER PROCEDURE 只更新元数据和源码文本，不触发重编译，也不清理任何缓存项

优先用 sp_recompile 标记重编译

比直接清缓存更安全、副作用更小：它只标记目标存储过程为“下次执行时必须重编译”，不打断其他查询，也不引发 CPU 尖峰。

• 执行命令：EXEC sp_recompile 'dbo.YourProcName'
• 支持按表名调用（如 EXEC sp_recompile 'SalesOrderHeader'），会连带重编译所有引用该表的存储过程
• 重编译发生在下一次调用时，不影响当前连接或并发请求
• 生产环境首选方案；若仍无效，再考虑清除缓存

精准清除单个存储过程的缓存计划

避免误伤全局——DBCC FREEPROCCACHE 不加参数会清空所有数据库的所有计划，而 DBCC FLUSHPROCINDB 只能按库粒度清除。真正精准的方式是定位 plan_handle 后清除。

• 先查目标过程的缓存项：SELECT plan_handle, cacheobjtype, objtype FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st WHERE st.objectid = OBJECT_ID('dbo.YourProcName') AND cp.objtype = 'Proc'
• 再清除单个计划：DBCC FREEPROCCACHE (0x060001002903DC0B4001B887000000000000000000000000)（把查到的 plan_handle 值填进去）
• Azure SQL 和 SQL Server 2016+ 支持 WITH NO_INFOMSGS 抑制输出，旧版本不识别该选项
• 注意：sys.dm_exec_query_stats 中的 sql_handle 对应语句级缓存，不能用于清除整个存储过程——必须用 plan_handle

别在生产环境直接跑 DBCC FREEPROCCACHE

它会让所有查询首次执行变慢，并可能引发瞬时 CPU 高峰。真要清，得确认三件事：

• 当前负载低：检查 sys.dm_exec_requests 是否有大量 status = 'running' 或长时间阻塞的会话
• 权限足够：需要 ALTER SERVER STATE，db_owner 不够
• 确认是唯一解：比如已排除 SET 选项不一致（如 ANSI_NULLS ON/OFF）、统计信息陈旧、或跨库引用导致 objectid 为空等干扰因素

最易被忽略的是：缓存计划可能对应多个 plan_handle（比如不同 SET 上下文、不同参数类型隐式转换），只清一个不一定彻底——得结合 sys.dm_exec_cached_plans 多次验证是否还有残留。