动态SQL执行计划缓存失效核心原因：SQL文本不一致导致无法复用计划，必须采用参数化查询、避免硬编码、规范排序与表名处理，并通过sys.dm_exec_query_stats验证execution_count是否增长。

动态SQL执行计划为何无法被缓存

SQL Server具备为动态SQL缓存执行计划的能力，但其生效的关键在于**严格的参数化一致性**。许多开发者误以为只要使用sp_executesql即可自动缓存，实则不然。若将变量值直接拼接至SQL字符串中，例如'WHERE id = ' + CAST(@id AS VARCHAR)，会导致每次生成的SQL文本均不相同，SQL Server会将其识别为全新的批处理，从而无法复用已缓存的执行计划。

• 首先，需确认使用的是EXEC(@sql)还是sp_executesql。前者（EXEC）默认不会缓存执行计划。
• 其次，检查参数占位符的写法：必须采用N'WHERE id = @id'的形式，并将@id作为独立参数传入，切勿将其值直接嵌入SQL字符串。
• 还需注意细节：SQL字符串字面量应添加Unicode前缀N''，若缺失可能引发隐式类型转换，进而影响计划匹配与缓存。

sp_executesql 参数化规范写法详解

实现执行计划缓存需要“全程参数化”，任何环节的拼接都可能导致缓存失效。常见误区是仅对主要条件进行参数化，而排序字段、表名等仍采用字符串拼接。只要SQL文本存在变动，缓存机制便无法生效。

-- ✅ 正确示例：所有可变部分均通过参数或安全白名单控制
DECLARE @sql NVARCHAR(MAX) = N'SELECT * FROM Orders WHERE Status = @status AND CreatedDate >= @from';
EXEC sp_executesql @sql, N'@status TINYINT, @from DATETIME', @status = 1, @from = '2024-01-01';

-- ❌ 错误示例：@orderby 直接拼接至字符串 → 每次SQL文本不同 → 缓存失效
SET @sql = N'SELECT * FROM Orders ORDER BY ' + @orderby;

• 针对排序、分页等动态字段，应通过白名单校验后映射，例如使用CASE @sortCol WHEN 'name' THEN name END结构。
• 表名、列名等数据库对象标识符无法直接参数化，需结合QUOTENAME()函数与白名单机制处理，否则不仅存在SQL注入风险，也会破坏执行计划缓存。
• 此外，避免在动态SQL内部直接引用外层存储过程的局部变量（如@localVar）。此类变量不会出现在sp_executesql的参数列表中，会被当作常量值内联到SQL文本中，同样会导致文本变化。

如何验证执行计划是否被成功复用

执行计划缓存是否生效需通过数据验证，重点利用sys.dm_exec_query_stats动态管理视图进行监测。

• 查询缓存中的执行计划：可执行类似SELECT plan_handle, sql_handle, execution_count FROM sys.dm_exec_query_stats WHERE sql_handle IN (SELECT sql_handle FROM sys.dm_exec_sql_text WHERE text LIKE '%Orders%Status%')的语句。
• 核心观察execution_count：多次执行同一动态SQL后，若该值大于1，则表明执行计划已被成功复用。
• 区分plan_handle与sql_handle：前者相同而后者不同，代表是不同的SQL语句；仅当sql_handle一致时，才表示SQL文本完全相同。
• 最后，确保语句中未使用OPTION (RECOMPILE)查询提示。一旦添加此提示，无论写法如何，执行计划都不会被缓存。

高并发下动态SQL缓存后仍缓慢？警惕参数嗅探问题

有时执行计划缓存虽成功，但性能反而下降，这常源于“参数嗅探”问题：首次编译时根据传入的参数值（例如返回少量数据的查询）生成了“特化”的执行计划。当后续调用传入差异巨大的参数值（例如需扫描大量数据的查询）时，SQL Server仍沿用原有低效计划，导致性能骤降。

• 临时解决方案：在查询中添加OPTION (OPTIMIZE FOR (@status UNKNOWN))提示，使优化器忽略参数具体值，生成通用型执行计划。
• 更稳健策略：针对关键业务分支，拆分为多个固定SQL语句（例如使用IF @type = 1 ... ELSE IF @type = 2 ...结构），使各分支拥有独立的缓存计划。
• 谨慎使用WITH RECOMPILE：此选项强制每次执行重新编译，彻底放弃缓存。仅适用于参数值分布极不均匀、执行计划可能差异巨大的极端场景。
• 对于SQL Server 2022及以上版本，可考虑启用ASSISTED QUERY PLAN FORCING功能，自动检测并修正劣质执行计划，但需评估环境兼容性。

本质上，性能瓶颈往往不在于“是否缓存”，而在于“是否缓存了低效计划并反复使用”。因此，持续监控execution_count与实际执行耗时，远比盲目优化SQL字符串拼接更为关键。