MySQL存储过程不缓存执行计划，所谓“陈旧计划”实为统计信息过期、数据量变化或隐式转换导致优化器误选路径；动态SQL须用sp_executesql并严格参数化，禁用EXEC(@sql)以保障计划复用。
动态SQL在存储过程中能解耦逻辑，但写错就彻底失去执行计划缓存——不是“能跑就行”，而是“每次调用都重编译”。关键不在拼字符串，而在让 SQL Server 或 MySQL 把它当同一句 SQL 处理。
必须用 sp_executesql，禁用 EXEC(@sql)
用 EXEC(@sql) 等于主动放弃缓存：SQL Server 视其为即席批处理，不进计划缓存；MySQL 5.7+ 也不支持缓存这类语句。而 sp_executesql 是唯一被设计用于参数化动态 SQL 的接口。
-
EXEC(@sql)：字符串硬编码 → 每次语句文本不同 →execution_count始终为 1 -
sp_executesql：参数分离 → 语句模板固定 → 只要sql_handle相同，就能复用计划 - 验证方法：
SELECT sql_handle, execution_count FROM sys.dm_exec_query_stats WHERE text LIKE '%your_table%'，多次调用后execution_count > 1才算成功
所有变量必须进参数列表，禁止拼接值到字符串中
哪怕只拼一个 @id 进字符串，整个语句文本就变了。比如 N'SELECT * FROM users WHERE id = ' + CAST(@id AS VARCHAR)，生成的语句是 ...WHERE id = 123 和 ...WHERE id = 456 —— 完全是两条不同语句。
- ✅ 正确写法：
N'SELECT * FROM users WHERE id = @id'+ 参数定义N'@id INT'+ 实际传参@id = 123 - ❌ 错误写法：
SET @sql = N'SELECT * FROM users WHERE id = ' + CAST(@id AS VARCHAR) - 注意 Unicode 前缀：
N''必须有，否则可能触发隐式转换，导致sql_handle不匹配
排序字段、表名、列名不能参数化，得用白名单 + QUOTENAME()
SQL Server 和 MySQL 都不允许把表名、列名、ORDER BY 字段直接当参数传。硬拼会破坏缓存，不校验则引入注入风险。
- 排序字段：用
CASE @sort_col WHEN 'name' THEN name WHEN 'created' THEN created END映射，再ORDER BY这个表达式 - 表名/列名：先检查是否在预设白名单里（如
IF @table_name NOT IN ('orders', 'customers') RAISERROR），再用QUOTENAME(@table_name)包裹 - 禁止用
EXEC('SELECT * FROM ' + @table_name)—— 即使加了QUOTENAME，语句文本仍随@table_name变，缓存失效
局部变量不能出现在 sp_executesql 参数外
存储过程里的局部变量（如 @local_flag BIT）如果没显式传进 sp_executesql 的参数列表，SQL Server 会在编译时把它当作常量内联进字符串——等于又拼了一次值。
- ❌ 错误：
DECLARE @local_flag BIT = 1; SET @sql = N'SELECT * FROM t WHERE flag = ' + CAST(@local_flag AS VARCHAR) - ✅ 正确：
SET @sql = N'SELECT * FROM t WHERE flag = @flag'; EXEC sp_executesql @sql, N'@flag BIT', @flag = @local_flag - 尤其注意游标循环中引用的变量，容易漏传
最易被忽略的一点：哪怕你每处都用了 sp_executesql，只要有一处排序字段靠拼接、或一个局部变量没进参数列表，整条语句就退化成硬编码——缓存形同虚设。验证别靠感觉，查 sys.dm_exec_query_stats 里的 execution_count 才算数。
