消除嵌套在可选外部应用中的 SQL 聚集索引查找

发布于 2024-11-06 20:33:08 字数 1103 浏览 3 评论 0原文

我正在运行 SQL Server 2008。我已经构建了一个带有许多可选参数的大型搜索查询(包含在用户定义的函数中)。结果的简化版本类似于:

Declare @optionalSubTableParameter as userDefinedTableType READONLY

select id
from table t

--here is optional parameter 1 (there are quite a few of these)
outer apply(
 select top (1) st.item
 from subTable st
 inner join @optionalSubTableParameter ostp
 on (ostp.value = st.item or ostp.value is null)
 where st.index = t.index 
 and ostp.value is not null
 -- also tried: (select top(1) * from @optionalSubTableParameter) is not null
)someParam

where (someParam.item is not null 
or (select top(1) * from @optionalSubTableParameter) is null)

所以,问题出在执行计划上,我似乎把时间花在:

聚集索引查找(聚集)

[subTable].[IX_subTableIndex ..

成本:8%

我知道 8% 并不算多,但这会重复 6 次(很快还会更多),所以它已经是我执行的 48%时间。

我认为通过在外部应用中检查 (@OptionalSubTableParameter is not null) ,我可以避免在不需要的表上进行聚集索引查找之类的计算(当没有指定参数时)。如果有人可以帮助解释是否有办法让我避免这种计算,那就太好了!

提前致谢,如果我可以澄清任何事情,请告诉我(这是我实际运行的查询的一个非常简化的版本)。

如果有任何重复的帖子,我深表歉意,但我自己没能找到答案。

I'm running SQL Server 2008. I've built a large search query (contained in a user defined function) with many optional parameters. A simplified version of the result is something like:

Declare @optionalSubTableParameter as userDefinedTableType READONLY

select id
from table t

--here is optional parameter 1 (there are quite a few of these)
outer apply(
 select top (1) st.item
 from subTable st
 inner join @optionalSubTableParameter ostp
 on (ostp.value = st.item or ostp.value is null)
 where st.index = t.index 
 and ostp.value is not null
 -- also tried: (select top(1) * from @optionalSubTableParameter) is not null
)someParam

where (someParam.item is not null 
or (select top(1) * from @optionalSubTableParameter) is null)

So, the problem lies in the execution plan, I seem to be spending time on:

clustered index seek (clustered)

[subTable].[IX_subTableIndex..

Cost:8%

I know 8% isn't much, but this gets repeated 6 times (and soon to be a few more), so its already 48% of my execution time.

I thought by having the check of (@optionalSubTableParameter is not null) within the outer apply, I would avoid computations like the clustered index seek on an unneeded table (when there is no parameter specified). If anyone can help explain if there is a way for me to avoid this computation, that would be great!

Thanks in advance, and let me know if I can clarify anything (this is a grossly simplified version of the query that I'm actually running).

I apologize if there are any duplicate posts, but I had no luck finding an answer on my own.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

情徒 2024-11-13 20:33:08

首先,这只是执行成本的 8%。如果您遇到性能问题,请继续寻找,因为这无法解决问题。

其次,由于这一行,您仍在进行索引查找:

where st.index = t.index

您可以通过切换 WHERE 的顺序来消除它该外部条款适用,但我不会指望它。

由于它是一个 AND ,我认为它可以评估这两个组件。其他人可能可以解决短路与否的问题。

First, this is only 8% of your execution cost. If you have performance issues, keep looking because this won't be the fix.

Second, you are still doing the index seek because of this line:

where st.index = t.index

You MAY be able to eliminate it by switching the order of the WHERE clause in that outer apply but I wouldn't count on it.

Since it's an AND I think it may evaluate both components. Someone else could probably address if that short circuits or not.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文