你是否总是期望参数嗅探引起的问题？

使用SQL Server 2008，我有一个简单的存储过程，其内容是你是否总是期望参数嗅探引起的问题？

DELETE FROM [ABC].[dbo].[LookUpPermissions] 
WHERE Code = @Code

在最近的代码审查，DBA说我应该“增加参数嗅探”，我相信意味着我应该考虑参数嗅探。我从来没有这样做过，我没有任何性能问题与查询，所以我认为这是没有必要的。

虽然我认为答案可能是用户偏好，但是最好的做法是解释参数嗅探？存储过程是否需要在小数据集上调用，不常使用并且没有性能问题？

编辑
这是仅适用于使用的参数WHERE子句，或例如，你可能需要在INSERT语句考虑到所有的参数？

来源

2011-12-22 earthling

[相关 - 如果你总是使用'OPTIMIZE FOR UNKNOWN']（http://stackoverflow.com/q/4376313/73226） – 2011-12-22 20:10:28

简单地搜索这样的单个值不应该容易受到参数嗅探的影响。当传递的参数产生大不相同的结果并且最佳执行计划与先前产生的结果不同时，更关心的是问题。

作为示例，请考虑查找日期列在@start_date和@end_date之间的行。调用日期范围为2天的过程可能会产生/缓存对于1年的日期范围不是最佳的执行计划。

来源

2011-12-22 20:13:16

这不取决于'Code'是否是'LookUpPermissions'的PK，或者“LookUpPermissions”是一个具有100000个条目的细节表，其中99％具有单个“代码”值，另一个1％具有各种其他“代码”？在第二种情况下，我会期待与您的日期情况相同的行为 - “代码”值的初始选择可能会影响查询计划。 – Tao 2011-12-27 14:42:27

thx。对where子句中没有使用的参数有何评论？ – earthling 2012-01-04 22:52:12

@senloe在INSERT（'INSERT INTO MyTable（Col1，Col2）VALUES（@ p1，@ p2）'）中使用的参数对生成的执行计划绝对没有影响，所以在这种情况下不会有参数嗅探的机会。 – 2012-01-04 22:55:45

-1

参数嗅探是Microsoft用于优化SQL查询的另一种内置“smarty thingy”（记住内联拼写/语法检查）。通过嗅探输入参数，SQL Server可以最有效地猜测哪个缓存查询计划是最好的计划。它并不总是做出正确的选择。

Read this for information on how to trick SQL into not using pramater sniffing。

来源

2011-12-27 14:18:14

他们并没有要求对什么参数嗅探进行模糊解释，或者如何采取预防措施以避免它。当**采取这些预防措施时，他们问**。 – 2011-12-27 20:52:33

你是否总是期望参数嗅探引起的问题？

回答

相关问题