Oracle数据库（含存储过程）是否存在参数嗅探问题？SQL Server优化是否滞后？

1. Oracle数据库是否存在参数嗅探？存储过程中呢？ #

• 答案是肯定的，Oracle里对应的概念叫绑定变量窥视（Bind Variable Peeking），本质就是参数嗅探：当SQL第一次硬解析时，优化器会使用传入的实际参数值生成执行计划，这个计划会被缓存到共享池中。后续执行相同SQL（即使参数不同）时，会直接复用这个缓存的计划。
• 存储过程里同样存在这个问题：存储过程中的SQL语句在首次执行时，同样会嗅探当时传入的参数生成计划并缓存，后续调用存储过程如果用差异很大的参数（比如一个参数对应1行数据，另一个对应100万行），就可能导致执行效率骤降。

2. 参数嗅探是bug还是特性？ #

严格来说，这更像是设计权衡带来的副作用，而非纯粹的bug：

• 最初引入绑定变量重用和参数嗅探，是为了减少硬解析的开销，提升系统整体吞吐量——这在数据分布均匀、参数差异不大的场景下非常有效，属于优化特性。
• 但当数据分布极度不均匀（比如某列有大量重复值，少数值对应超大数据集），或者参数范围差异极大时，复用基于“第一个参数”生成的计划就会导致性能灾难，这时候它就表现得像个“bug”。Oracle后续也推出了很多缓解方案（比如自适应游标共享、SQL计划基线），就是为了平衡绑定变量重用和计划适应性的矛盾。

3. SQL Server在修复估算/计划缓存问题上是否滞后？ #

不能简单说滞后，不同数据库的优化思路和迭代节奏各有侧重：

• 早期SQL Server在处理参数嗅探问题上，确实更多依赖DBA手动干预（比如OPTION (RECOMPILE)、OPTIMIZE FOR提示），自动处理能力不如Oracle成熟——Oracle早在11g就推出了自适应游标共享，12c后又加强了自适应执行计划。
• 但从2016版本开始，SQL Server逐步补上了这块短板：2016引入了查询存储（Query Store），可以跟踪计划变化、强制使用好的计划；2017的自动查询调优（包括自动计划修正、自动索引建议）更是把计划缓存问题的自动处理提升到新高度。
• 对比其他DBMS，SQL Server的解决方案更侧重“自动化+可观测”，比如查询存储让DBA能直观看到计划的优劣，自动修正功能可以自动替换有问题的执行计划。现在来看，它在计划缓存问题的修复能力上已经和其他主流DBMS处于同一梯队，甚至在某些自动化场景下更便捷。

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