执行计划改变是优化器对环境变化的正常响应，而非bug；参数嗅探、统计信息过期、SET选项不一致、动态SQL写法不当等均会导致计划劣化。

执行计划改变不是“出 bug”，而是 SQL Server 或 Oracle 在按规则响应环境变化——参数值、统计信息、SET 选项、索引结构这些只要有一个变了，优化器就可能换计划。

参数嗅探（Parameter Sniffing）让首次值决定后续命运

SQL Server 编译存储过程时会“嗅探”第一次传入的 @status 值，并据此生成计划；如果首次是 @status = 'archived'（仅 0.1% 行），它大概率选索引查找 + RID Lookup；之后调用 @status = 'active'（95% 行）仍复用该计划，逻辑读暴增。

• 验证方法：查 sys.dm_exec_query_stats 中同一 sql_handle 的多次执行，对比 total_logical_reads 和 execution_count 是否剧烈波动
• 典型信号：EstimateRows 在执行计划 XML 中远小于实际扫描行数（比如预估 1 行，实际读 40 万页）
• 别一上来就加 OPTION (RECOMPILE)——高并发下 CPU 会扛不住

统计信息过期或更新不完整直接误导优化器

优化器靠统计信息估算行数，一旦数据量翻倍、新增覆盖索引、或删了低效索引，旧计划就可能失效。SQL Server 2022 默认自动更新阈值是“20% 行变更 + 500 行”，对千万级表基本不起作用。

• 手动触发更准：UPDATE STATISTICS table_name WITH FULLSCAN
• 检查碎片：sys.dm_db_index_physical_stats 中 avg_fragmentation_in_percent > 30 的索引建议 REBUILD
• 注意：REORGANIZE 不更新统计信息，REBUILD 会自动更新

SET 选项不一致导致计划“互相不认识”

哪怕两个连接执行完全一样的存储过程，只要一个开了 SET ARITHABORT ON、另一个没开，SQL Server 就认为它们是不同上下文，各自编译、各自缓存——结果就是 usecounts = 1，看似快了，实则每次都在硬编译。

• 查当前会话：SELECT SESSIONPROPERTY('ARITHABORT')（返回 1=ON，0=OFF）
• ORM（如 Entity Framework）默认发 SET ARITHABORT ON，而 SSMS 默认关着——这就是为什么 SSMS 测得快、上线就慢
• 避免在过程中动态改 SET：SET ANSI_NULLS OFF 后再查表，会强制整条语句重编译

动态 SQL 写法彻底绕过计划缓存

用 EXEC(@sql) 拼接字符串，SQL Server 把每次生成的语句当全新 SQL 处理，根本不会进缓存；哪怕只差一个空格，哈希值就变，缓存形同虚设。

• ✅ 正确写法：EXEC sp_executesql N'SELECT * FROM Orders WHERE Status = @status', N'@status TINYINT', @status = 1
• ❌ 错误写法：SET @sql = N'SELECT * FROM Orders WHERE Status = ' + CAST(@status AS VARCHAR); EXEC(@sql)
• 排序字段、表名、列名不能参数化，必须用 QUOTENAME() + 白名单校验，否则既不安全也破坏缓存

真正难处理的不是某一次计划变差，而是多个因素叠加：比如统计信息刚更新完、恰好又来了个极端参数、客户端还带着不同的 SET 选项——这种组合会让问题极难复现，也最容易被归因为“数据库抽风”。盯住 plan_generation_num 和 sys.dm_exec_query_stats 的波动，比猜原因更可靠。