sp_recompile 是最轻量安全的重编译方式：仅标记存储过程，下次执行时自动重建计划；不立即编译、不清空全部缓存、不影响业务，适合怀疑计划老化或统计信息过期时使用。
直接用 sp_recompile 标记存储过程，下次执行自动重编译
这是最轻量、最安全的重编译方式：不立刻触发编译，只清空当前缓存计划，让下一次调用时「自然重建」。适合日常维护或怀疑计划老化、统计信息过期但不想中断业务的场景。
执行前先确认过程名存在且拼写准确，大小写敏感取决于实例排序规则：
USE YourDatabaseName; GO EXEC sp_recompile N'uspGetSalesInfoForDateRange';
注意：sp_recompile 不会报错也不返回成功提示，执行完查 sys.dm_exec_cached_plans 就能看到对应计划已消失。下次 EXEC uspGetSalesInfoForDateRange '2025-01-01', '2025-01-31' 时，SQL Server 会重新生成执行计划。
常见误操作：
- 传入表名而非过程名（如
EXEC sp_recompile N'Orders'）——这会触发所有引用该表的存储过程和触发器重编译，影响面不可控 - 在错误数据库上下文中执行（没加
USE或用错了库）——过程名查不到，命令静默失败 - 对已删除的过程执行——无报错，但无效
用 WITH RECOMPILE 强制单次或全程重编译
这不是“刷新缓存”，而是绕过缓存机制本身。分三种写法，成本和适用性差异极大：
-
调用时加：
EXEC uspGetSalesInfoForDateRange '2025-01-01', '2025-01-31' WITH RECOMPILE—— 仅本次执行丢弃旧计划、全量重编译，DBA 救急专用，绝不能写进应用代码 -
创建时加：
CREATE PROCEDURE uspReport @date DATE WITH RECOMPILE AS ...—— 每次执行都从零编译，CPU 开销高，只适用于参数组合完全随机（如 BI 工具动态传参）、且日均调用次数低于 10 次的场景 -
语句级加：
SELECT * FROM Orders WHERE OrderDate >= @from OPTION (RECOMPILE)—— 只重编译这一句，其余逻辑仍走缓存计划，适合过程里某条查询因参数值极端导致计划失优（比如 99% 查询查 1 天数据，1% 查 365 天），而其他语句稳定的 case
关键区别：带 WITH RECOMPILE 的过程无法被计划缓存复用；而 OPTION (RECOMPILE) 是查询提示，只影响本句，且能感知本地变量值（WITH RECOMPILE 过程级不感知）。
为什么有时重编译后反而更慢？重点排查这三件事
重编译不是性能银弹，盲目操作可能雪上加霜：
-
参数嗅探未解决：先查执行计划 XML，看
Parameter Compiled Value是否和实际传入值严重偏离（比如编译时传了'2025-01-01'，但运行时传了'2020-01-01'）。真问题是参数嗅探，重编译只是掩盖症状 -
统计信息滞后：用
DBCC SHOW_STATISTICS('Orders', 'IX_OrderDate')看Modification Counter。如果远大于Rows Sampled * 0.2，说明统计信息过期，应先UPDATE STATISTICS Orders WITH FULLSCAN，而不是直接重编译 -
SET 选项不一致：客户端连接时
SET ARITHABORT ON，而过程内没显式设，或反之——会导致同一语句生成多个缓存计划，徒增编译压力。统一在过程开头加SET ARITHABORT ON可收敛
临时表也是高频雷区：只要过程里建了 #TempTable 并插入 >500 行，SQL Server 就会在插入后自动更新其统计信息，触发隐式重编译。这种重编译无法避免，但可通过改用表变量（@TempTable）规避——前提是数据量小、不需统计信息驱动优化。
别漏掉计划缓存污染这个隐形杀手
一个存储过程被频繁重编译，有时根本不是它自己有问题，而是整个计划缓存被污染了。比如 DBA 执行过 DBCC FREEPROCCACHE，或者做了数据库分离/附加、升级，都会清空全部缓存。此时所有存储过程首次执行都会重编译，看起来像“过程本身不稳定”。
快速验证方法：
SELECT
objtype,
COUNT(*) AS plan_count,
SUM(cached_time) AS total_cached_time
FROM sys.dm_exec_cached_plans
GROUP BY objtype;如果 objtype = 'Proc' 的数量极少（比如个位数），而 Adhoc 占比异常高，大概率是缓存刚被刷过。这时候单独重编译某个过程意义不大，得等业务流量把常用计划慢慢填回来。
