如何解决 SQL Server 2000 上的参数嗅探？答案

【问题标题】：How can I cure parameter sniffing on SQL Server 2000?如何解决 SQL Server 2000 上的参数嗅探？
【发布时间】：2012-10-30 17:32:56
【问题描述】：

我遇到了一个问题，其中包含大约 70 个参数的更新查询有时会超时。根据一些研究，我相信这是由于数据包嗅探。我看到在较新版本的 SQL Server 中，我可以使用 Option(recompile) 子句，但在我的情况下这不起作用，因为我使用的是服务器 2000。

我使用的是sqlhelper.executeNonQuery，而不是存储过程。

【问题讨论】：

@MitchWheat 我没有大量的 SQL Server 经验，所以这可能是我在本次讨论中的一个缺点。但是，我还没有重建索引和更新统计信息。你的帖子有一个关于在 Prod 中做这些的警告。我应该关心什么？该表确实参与了复制。

标签： sql sql-server sql-server-2000 parameter-sniffing

【解决方案1】：

据我所知，没有像Option(recompile) 这样的“开箱即用”方式，但我记得我找到了一种欺骗优化器的方法。它似乎只嗅探您实际上在查询外部传递的参数，而不是全部。所以，如果你尝试运行

SELECT MyField1, MyField2 FROM MyTable WHERE MyOtherField = @MyParm

参数嗅探会发生，但是如果你写类似的东西

DECLARE @MyUnsniffableParm varchar(30)
SET @MyUnsinffableParm = @MyParm    
SELECT MyField1, MyField2 FROM MyTable WHERE MyOtherField = @MyUnsniffableParm

ad 当然只是将@MyParm 参数传递给您的脚本，参数嗅探似乎不会发生！让我知道如果我没记错的话，我没有 SQL 2000 实例可以尝试！
编辑：
看起来其他东西在这里做同样的事情：http://blogs.msdn.com/b/khen1234/archive/2005/06/02/424228.aspx

【讨论】：

这将导致一个非常通用的执行计划，适用于所有参数的所有值，就像option (optimize for unknown) 那样。这可能是一个不错的选择，但它并没有像option (recompile) 那样为当前参数的具体值提供执行计划。

【解决方案2】：

一个简单的解决方法是不使用参数。而不是：

SELECT * FROM YourTable WHERE UserName = @myUserName;

通过：

SELECT * FROM YourTable WHERE UserName = 'PFranchise'

如果 SQL Server 不知道参数，它就无法嗅探它们！ SQL Server 将为每个查询重新编译查询计划。

关于这种方法的两个注意事项：

小心 SQL 注入
在更高版本的 SQL Server 中，server option "forced parameterization" 甚至可以嗅探没有参数的查询。默认情况下它是关闭的。但在升级 SQL Server 时需要牢记这一点。

【讨论】：

这似乎是一种可靠的方法。对于更新语句，是否需要替换所有@attributes（那些在update 和where 子句中使用的），还是只替换where 子句中的那个？我的意思是，UPDATE [table] SET val1=@val1 WHERE UserName = 'Pfranchise' 足够好，还是我也需要替换@val1？作为参考，我的查询有 1 个 where 和 ~74 vals。
您只需要替换 where 值。但是——where 子句中只有一个变量，参数嗅探根本不应该成为问题！也许您可以进一步解释您遇到的问题类型？
这是我原始问题的链接，它更详细地解释了我遇到的问题。 stackoverflow.com/questions/13013486/…
好的。在这种情况下，参数嗅探不太可能成为问题。检查表VendorInfo 的定义以及ID 列上是否有索引。如果没有，添加它，例如alter table VendorInfo add constraint PK_VendorInfo primary key (id)
好的，谢谢您的信息。 id 已经是该表的 PK，如果我没记错的话，这意味着它应该已经有一个索引。