临时表与常量语句重编译：动态SQL压力测试问题咨询

听起来你在压力测试中遇到的这个问题，在复杂的事务+多存储过程+动态SQL场景里确实很典型——常量语句重编译不仅会吃掉大量CPU资源，还会导致执行计划不稳定，在高并发下性能波动会被放大。结合你的具体场景，我整理了几个针对性的解决思路：

1. 从临时表本身入手，减少元数据/统计信息触发的重编译 #

• 显式预定义临时表结构：不要用SELECT ... INTO #temp这种依赖查询结果生成结构的方式，而是在事务最开始就用CREATE TABLE #temp (列名 类型, ...)明确定义所有列。这样避免后续因为查询结果结构变化导致的元数据变更重编译。
• 手动维护临时表统计信息：临时表的自动统计更新阈值在批量插入数据时可能不够及时，建议在完成临时表的填充后，执行UPDATE STATISTICS #YourTempTable WITH FULLSCAN，给优化器提供准确的基数估计，减少因统计信息过时触发的重编译。
• 避免跨存储过程修改临时表结构：如果多个存储过程都操作同一个临时表，确保只在事务初始化时创建结构，后续只做插入/更新/查询操作，不要在动态SQL里执行ALTER TABLE这类会修改元数据的语句。

2. 优化动态SQL写法，最大化执行计划重用 #

• 完全参数化所有变量，杜绝常量拼接：你已经在用sp_executesql，这很好，但要确保所有可变值都通过参数传递，而不是直接拼到SQL字符串里。比如不要写：

  DECLARE @SQL NVARCHAR(MAX) = N'SELECT * FROM #temp WHERE ID = ' + CAST(@ID AS NVARCHAR(10))
  EXEC sp_executesql @SQL
  

  而是改成：

  DECLARE @SQL NVARCHAR(MAX) = N'SELECT * FROM #temp WHERE ID = @ID'
  EXEC sp_executesql @SQL, N'@ID INT', @ID = @ID
  

  这样不管@ID的值是什么，SQL文本都是一致的，能直接重用执行计划，避免因常量不同导致的重复编译。
• 统一动态SQL的格式规范：SQL Server对执行计划缓存的匹配是基于SQL文本的精确匹配，哪怕多一个空格、大小写不一致都会被视为不同的语句。生成动态SQL时要统一格式（比如固定大小写、统一空格），减少不必要的计划缓存膨胀。

3. 精准控制参数嗅探与编译行为 #

• 针对性使用OPTION (RECOMPILE)：如果某些复杂的SELECT（比如包含UNION ALL/UNPIVOT的语句）确实因为参数差异导致执行计划质量波动极大，可以在该语句末尾添加OPTION (RECOMPILE)，但不要全局给整个存储过程加——这样只会增加编译开销。只在真正需要的单条语句上使用，平衡编译成本和执行计划质量。
• 用OPTIMIZE FOR锁定代表性参数：如果你的业务有一个高频的代表性参数值，可以在语句里加OPTION (OPTIMIZE FOR (@Param = 123))（替换成你的典型值），让优化器基于这个值生成通用计划，避免因异常参数触发的重编译或差计划。
• 检查SET选项一致性：不同的SET选项（比如ANSI_NULLS、QUOTED_IDENTIFIER）会导致相同的SQL生成不同的执行计划。确保所有调用动态SQL的存储过程/批处理的SET选项一致，避免因选项差异触发的重编译。

4. 重构复杂查询与UDF，减少编译触发点 #

• 替换标量UDF为内联表值UDF：标量UDF会触发逐行处理，不仅性能差，还可能因为UDF的定义变化或统计信息问题触发重编译。把标量UDF改成内联表值UDF（无BEGIN/END的那种），优化器会把它展开成查询的一部分，性能更好，也更稳定。
• 简化复杂的UNION ALL/UNPIVOT逻辑：对于包含多个UNION ALL分支的查询，确保每个分支的列类型、顺序完全一致，避免隐式转换触发重编译。另外，可以尝试用CROSS APPLY VALUES替代UNPIVOT，有时候能生成更稳定的执行计划。

5. 排查重编译根源 #

• 用Extended Events跟踪SQL:StmtRecompile事件，查看重编译的具体原因（比如Schema Changed、Statistics Changed、Set Option Changed等）。找到具体触发点后再针对性解决，比盲目优化更高效。

内容的提问来源于stack exchange，提问作者Dan Def