我有这样的观点,大约需要2分钟才能执行。
select col1, col2, col3, col4, ...,
from table1
inner join table2 on condition1
inner join table3 on condition2
inner join table4 on condition3
....
left outer join table12 on condition11
left outer join table13 on condition12
...
where condition13 and condition14 and condition15
但是如果我在视图中添加OR
条件,性能会急剧增加,大约需要13秒。在这种情况下,OR
条件永远不会成立。 col1
是table2
的主要关键,任何想法都会发生这种情况,并且有一种巧妙的方法来实现这些结果。
OR table2.col1 = 0
更改查询:
select col1, col2, col3, col4, ...,
from table1
inner join table2 on condition1
inner join table3 on condition2
inner join table4 on condition3
....
left outer join table12 on condition11
left outer join table13 on condition12
...
where condition13 and condition14 and condition15 OR table2.col1 = 0
提前致谢
答案 0 :(得分:0)
我设计了两个简单的POC:
Case A
,http://sqlfiddle.com/#!18/d0c53/1,以及带有过滤器的直接inner join
Case B
,http://sqlfiddle.com/#!18/d0c53/5,具有相同的inner join
和相同的过滤器,加上ORed
条件不会产生额外的结果请检查两种情况的执行计划,单击链接查看执行计划。
对于Case A
,存在一个嵌套循环(具有非聚集索引搜索),对于Case B
,则可能会减少耗时的合并联接(尽管肯定会更多)缓冲区空间要求高。
相同的结果集,非常不同的执行计划。
考虑到您的问题,这些情况向我们展示了什么?好吧,对不起,除了布洛克。
我试图在这里证明查询中的一个调整会产生与SQL Server引擎完全不同的行为。
更多信息,此处未显示:统计信息的准确性和新鲜度对引擎计划的影响甚至更大-突然之间,由于统计信息(而不是数据)或统计信息的变化,快速查询可能会变得缓慢。查询本身。
由于您没有提供任何实际数据和查询,因此您必须调查自己的常规查询计划,以设计两个查询的行为为何如此不同。
而且,欢迎来到这个查询优化的美好世界!希望你喜欢。