Question

所有

当我在使用一个在开头设置值的变量与在查询中实际使用该值作为常量之间的性能方面运行查询时，我看到一些非常奇怪的行为。

我所看到的是

DECLARE @ID BIGINT
SET @ID = 5
SELECT * FROM tblEmployee WHERE ID = @ID

跑得比跑步时快得多

SELECT * FROM tblEmployee WHERE ID = 5

这显然是实际查询的一个更简单的版本，但有人知道SQL Server 2005中的已知问题，它解析可以解释此行为的查询。我的原始查询在两种方法之间从13秒到8分钟。

谢谢，阿希什

Answer 1

你确定是这样的吗？

通常，参数化查询会更慢，因为SQL Server事先并不知道参数是什么。可以立即优化常数。

有关数据类型的一点需要注意..这是做什么的：

SELECT * FROM tblEmployee WHERE ID = CAST(5 as bigint)

另外，反转执行顺序。前几天我们看到了一些奇怪的东西，当我们改变秩序时，计划也发生了变化。

另一种方法，删除“参数嗅探”的掩码ID会影响第一个查询。和差异？

DECLARE @ID BIGINT
SET @ID = 5
DECLARE @MaskedID BIGINT
SET @MaskedID = @ID
SELECT * FROM tblEmployee WHERE ID = @MaskedID

最后，为每个查询添加OPTION（RECOMPILE）。这意味着该计划被丢弃而不能重复使用，因此编译方式不同。

Answer 2

您是否检查过每个查询计划？当我试图分析性能问题时，这总是我做的第一件事。

Answer 3

如果值被缓存，您可能会得出一个毫无根据的结论，即一种方法比另一种方法更快。总有这种差异吗？

Answer 4

根据我的理解，它与缓存的查询计划有关。

当你从A中运行Select *时B = @C它是一个查询计划，无论@C的值如何。因此，如果您使用@C的不同值运行10x，则它是单个查询计划。

当你跑步时：

Select * from A Where B = 1 it creates a query plan
Select * from A Where B = 2 creates another
Select * from A Where B = 3 creates another

等

所有这一切都会耗尽记忆。

谷歌查询计划缓存和文字，我相信你会发现详细解释