gpt4 book ai didi

sql-server - 为什么参数化查询产生比非参数化查询慢得多的查询计划

转载 作者:行者123 更新时间:2023-12-02 00:53:16 24 4
gpt4 key购买 nike

在 SQL Server 2005 数据库中,我正在处理以下查询:

select *
from foo
join bar on bar.x = foo.x
join baz on baz.y = foo.y
where foo.x = 1000

与以下参数化版本相比,具有截然不同且更快的查询计划。

declare @p0 int
set @p0 = 1000
select *
from foo
join bar on bar.x = foo.x
join baz on baz.y = foo.y
where foo.x = @p0

在我的特殊情况下,带有文字的版本在亚秒内运行。参数化版本需要 2-3 秒。鉴于它们是相同的查询,我希望它们是相同的。

为什么他们会得到不同的查询计划?

有什么办法可以让参数化版本具有与字面版本相同的性能吗?

以下是查询计划。我的真实查询与我上面给出的通用查询有很大不同,但是生成这些计划的两个查询之间的唯一区别是参数。为什么用参数替换文字会导致计划差异如此之大?

最佳答案

看来查询规划器已经在文字查询中做出了基于其已有信息的决定。它将具有统计信息,可以根据特定文字中给出的数据分布有效地查询这些统计信息。

参数化查询选择了它认为对表中所有数据最公平的查询,您会注意到其中有许多嵌套循环(性能 = 糟糕)。

也许您可以尝试在数据库上运行数据库优化工具,看看某些索引是否可以帮助您?

具体来说,在您的查询中,请尝试以下操作:

declare @p0 int
set @p0 = 1000
select *
from foo
join bar on bar.x = foo.x
join baz on baz.y = foo.y
where foo.x = @p0
OPTION ( OPTIMIZE FOR (@p0 = 1000))

但是,如果不确定此查询中包含的数据不会更改并且您对此计划的查询始终会更高效,那么我会对此保持谨慎。

关于sql-server - 为什么参数化查询产生比非参数化查询慢得多的查询计划,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/510214/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com