消除嵌套在可选外部应用中的 SQL 聚集索引查找
我正在运行 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
首先,这只是执行成本的 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.