问题描述
答案还不完全，但是我会分享我的经验。
当我转向主要从事DBA的工作后，我回到Developer DBA时，参数嗅探花了我几年的sql Server来e住我。我对引擎，sql的工作方式，对客户的最佳了解等方面的知识更多，而我是一个更好的sql编码器。
例如，动态sql或CURSOR或普通的错误sql代码可能永远不会遭受参数嗅探。但是更好的集合编程或如何避免动态sql或更优雅的sql的可能性更大。
我注意到它适用于复杂的搜索代码（大量条件）和复杂的报告，其中参数默认值影响了计划。当我看到经验不足的开发人员将如何编写此代码时，它就不会受到参数嗅探的困扰。
无论如何，与WITH RECOMPILE相比，我更喜欢使用参数掩码。无论如何，更新统计信息或索引都会强制重新编译。但是为什么要一直重新编译呢？我已经在其他地方用一个链接回答了您的一个问题，其中提到在编译过程中会嗅探到参数，因此我也不相信它。
是的，参数屏蔽是一项开销，但是，它允许优化器根据情况评估查询，而不是一揽子重新编译。特别是在sql Server 2005的语句级重新编译的情况下
sql Server 2008中的“未知”优化似乎与屏蔽完全相同。我和我的sql Server MVP同事花了一些时间进行调查，并得出了这个结论。
解决方法
再次今天，我遇到了一个重大问题，似乎是SQL Server 2005中的参数嗅探。
我有一个查询，将一些结果与已知的良好结果进行比较。我在结果和已知的良好结果中添加了一个列，这样，每个月我都可以在双方加载新的月结果，并仅比较当月。新列在聚集索引中排在第一位，因此新的月份将添加到末尾。
我在我的WHERE子句中添加了一个条件-这是代码生成的，因此它是一个文字常量：
WHERE DATA_DT_ID = 20081231 -这是多余的，因为现在所有DATA_DT_ID均为20081231。
性能至关重要。从7秒钟比较大约150万行到2个小时，什么也没完成。直接在SSMS中运行生成的SQL-无SP。
我一直使用SQL
Server已有12年了，自10月以来，我从未在此生产服务器上遇到过如此多的参数嗅探问题（内部版本9.00.3068.00）。而且在每种情况下，这都不是因为它是第一次使用不同的参数运行或更改了表。这是一个新表，仅在使用此参数或根本没有WHERE子句的情况下运行。
而且，不，我没有DBA访问权限，并且他们没有给我足够的权限来查看执行计划。
到现在为止，我不确定是否只有几年的经验才能将这个系统提供给SQL Server用户。
UPDATE 结果表明，尽管统计信息声称是最新的，但使用FULLSCAN运行UPDATE STATISTICS可以解决此问题。
最终更新 即使使用WITH RECOMPILE和UPDATE STATISTICS重新创建SP，也发现必须以另一种方式重写查询，才能使用NOT
IN而不是带有NULL检查的LEFT JOIN。