2017-03-31 77 views
0

我目前正在尝试编写一个查询来筛选我们的ERP数据库,当我删除一个过滤条件时,我发现速度非常奇怪。为什么这些SQL查询之间的速度差异?

这是查询看起来像之前(花了一秒钟即可完成,通常为10返回随时随地数百记录取决于订单和项目上少)

SELECT TOP 1000 jobmat.job, jobmat.suffix, jobmat.item, jobmat.matl_qty, 
     jobmat.ref_type, jobmat.ref_num, spec.NoteContent, spec.NoteDesc, 
     job.ord_num, jobmat.RowPointer 
FROM jobmat 
INNER JOIN ObjectNotes AS obj ON obj.RefRowPointer = jobmat.RowPointer 
INNER JOIN SpecificNotes AS spec ON obj.SpecificNoteToken = spec.SpecificNoteToken 
INNER JOIN job ON job.job = jobmat.job AND job.suffix = jobmat.suffix 
WHERE ord_num LIKE '%3766%' AND ref_type = 'P' AND 
(spec.NoteDesc LIKE '%description%' OR spec.NoteContent LIKE '%COMPANY%DWG%1162402%') 

而这就是我改变了WHERE语句太:

WHERE ord_num LIKE '%3766%' AND ref_type = 'P' AND 
spec.NoteContent LIKE '%COMPANY%DWG%1162402%' 

它运行后作出这一modifcation我撞到了运行时喜欢9秒(正常返回1-3记录)。有没有一个明显的原因,我错过了?我原以为这同样应该大致相同。任何帮助是极大的赞赏!

编辑:我已经运行这个查询的两个版本多次测试,并且运行时间相当一致; <版本1为1秒,版本2为9秒。

+1

您是否多次运行此查询?因为性能还可能取决于机器上发生的其他事情。 –

+0

什么是您正在使用的DBMS,也可以粘贴两个版本的执行计划 – TheGameiswar

+0

@WillemVanOnsem我已经多次运行两个版本,并且运行时间对每个版本都是一致的。 – padleyj

回答

0

您的原始查询在返回结果集之前必须找到1000个匹配的行。它是通过创建基于JOIN的结果集并根据WHERE子句进行筛选来完成的。

条件:

(spec.NoteDesc LIKE '%description%' OR spec.NoteContent LIKE '%COMPANY%DWG%1162402%') 

比赛更多的行比:

(spec.NoteContent LIKE '%COMPANY%DWG%1162402%') 

因此,第二个版本都必须经过和处理更多的行获得1000场比赛。

这就是为什么第二个版本更慢。

如果您希望第二个版本看起来更快,您可以添加ORDER BY子句。这需要阅读两种情况下的所有数据。因为ORDER BY然后需要额外的时间与匹配行的数量有关,您可能会看到第二个比第一个稍快。一个警告:两者至少需要9秒钟。

编辑:

我喜欢上面的解释,但如果所有的行这两种情况进行处理,那么它可能是不正确的。这是另一种解释,但它更具推测性。

这取决于NoteContent很长,因此LIKE对查询性能有显着影响。第二个版本可能会通过在读取数据的处理中将过滤子句推送到节点进行“优化”。这是SQL Server经常做的事情。这意味着LIKE正在处理全部数据在第二种情况下。

由于OR条件,第一个示例不能将筛选降到该级别。然后,NoteDescription上的条件会以多种方式短路:

  • 连接条件。
  • 其他WHERE条件。
  • 第一个LIKE条件。

由于所有这些过滤,第二个条件运行在更少的行上,代码运行速度更快。通常在加入之前进行过滤是一个好主意,但这个规则肯定是例外。

+0

请注意,这些查询都没有返回超过1000的上限,这对您的解释是否有用?哦,也是第一个版本只需要1秒。 – padleyj

+0

@padleyj。 。 。是的,这确实会影响这个解释。在这种情况下,可能只是因为第一个查询更快地看到结果,因为它可以更快地获取数据。 –

+0

我也考虑过短路情况,所以我用<'0' = '1'>替换了,并且足够奇怪,仍然使运行时间增加到9秒。我越是摆弄它,我越确定你是对的,它与NoteContent有关。 – padleyj