存储过程执行计划变慢或失效并非“坏了”，而是sql server主动丢弃或拒绝复用：plan_generation_num＞1表明已重编译；set选项不一致（如arithabort差异）导致缓存上下文隔离；统计信息过期使优化器判定旧计划不再适用。
为什么存储过程执行计划会变慢或失效
不是执行计划“坏了”，而是 SQL Server 主动丢弃或拒绝复用它。常见触发点有三个：plan_generation_num 大于 1（说明被重编译过）、SET 选项不一致（比如一个调用带 SET ARITHABORT ON，另一个没设）、统计信息过期导致优化器认为旧计划不再适用。你看到的“越跑越慢”，大概率是某次调用触发了重编译，后续所有调用都沿用了为那次极端参数生成的低效计划。
- 查重编译：运行
SELECT plan_generation_num, execution_count, total_logical_reads FROM sys.dm_exec_query_stats s CROSS APPLY sys.dm_exec_sql_text(s.sql_handle) t WHERE t.text LIKE '%your_proc_name%'，若plan_generation_num > 1就确认发生了重编译 - 查 SET 不一致：用
sys.dm_exec_cached_plans+sys.dm_exec_plan_attributes查set_options值，不同值 = 不同缓存上下文 - 查统计信息：对关键表运行
DBCC SHOW_STATISTICS('TableName', 'IndexName')，看Modification Counter是否远大于Rows Sampled * 0.2
SQL Server 2022 新特性怎么用上
2022 自带的 PARAMETER_SENSITIVE_PLAN（PSP）是解决参数嗅探失准最轻量的方案，不需要改代码、不依赖查询提示，但必须满足两个前提：查询已参数化（即用 @param 而非字符串拼接），且列上有直方图能识别数据倾斜。它会在首次编译时自动识别高风险谓词（最多三个），并为不同参数范围生成多个 查询变体，运行时按实际值路由到对应计划。
- 开启方式：数据库级启用即可，执行
ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SENSITIVE_PLAN = ON - 验证是否生效：查
sys.query_store_plan，plan_forcing_type_desc出现ParameterSensitivePlan即表示 PSP 已介入 - 注意边界：PSP 不处理动态 SQL 中拼进来的列名/表名；也不覆盖
OPTION (RECOMPILE)或显式QUERYTRACEON的行为
临时表和表变量怎么选才不拖慢计划
临时表（#temp）每次执行都会建物理结构、生成统计信息、触发重编译，而表变量（@table_var）无日志、无统计、基数固定估为 1 行——两者都不是银弹，错配就会让执行计划崩坏。
- 用
@table_var：行数 ≤ 100、只做单次 INSERT + 单次 JOIN、后续不参与复杂过滤或聚合 - 用
#temp：行数 > 500、需多次增删改查、要建索引、JOIN 大表前必须有准确基数（此时记得加UPDATE STATISTICS #temp） - 更优解：直接用 CTE 或窗口函数替代中间集，例如把「先塞用户 ID 到 #tmp，再 JOIN 订单表」改成
SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC)
动态 SQL 怎么写才能复用执行计划
sp_executesql 不等于自动缓存。只要语句文本（sql_handle）变了，就进不了同一缓存槽位。典型破环行为是把排序字段、WHERE 条件甚至表名直接拼进字符串。
- 安全白名单控制可变部分：比如
@sort_col只允许'name'、'created_date'，用CASE @sort_col WHEN 'name' THEN name END替代字符串拼接 - 表名/列名必须用
QUOTENAME()包裹，且仅限预定义列表，不能接受任意输入 - 局部变量不能出现在动态 SQL 字符串里：写成
@sql = N'SELECT * FROM Orders WHERE id = @id'，然后在sp_executesql参数列表中传入@id，否则会被当常量内联，破坏参数化
执行计划不是“设好就一劳永逸”的配置，它是运行时环境、参数分布、统计信息三者耦合的结果。SQL Server 2022 的 PSP 功能虽好，但只对参数化查询起效；而临时表滥用、SET 选项混乱、动态 SQL 拼接这些老问题，依然会绕过所有新机制，直接让优化器回到“盲猜”状态。
