为什么同一场上的多个模糊LIKE查询比一个组合模糊LIKE更快？

Question

我正在分析在Amazon RDS上运行的SQL Server 2017探查器中的一些查询，并且遇到了一些意想不到的性能结果。

这两个查询返回相同的结果，我希望第一个查询更快，因为它仅限于一个LIKE。但事实上，第二个查询一直更快（查询1平均为350毫秒，查询2平均为300毫秒）。

我很好奇是否有人可以解释为什么查询2比查询1更快？

查询1 (Query Plan)

select * from Vehicles 
where vehicle like '%02%toyota%camry%'

查询2 (Query Plan)

select * from Vehicles 
where vehicle like '%02%' and vehicle like '%toyota%' and vehicle like '%camry%'

Vehicles表有500K行。 vehicle字段是索引varchar(300)，这是一些匹配行的示例：

2002 Toyota Camry LE 2.4L (2AZFE) 4-spd (U140E)
2002 Toyota Camry LE 2.4L (2AZFE) 4-spd (U140E)
2002 Toyota Camry LE 2.4L (2AZFE) 4-spd (U241E)
2002 Toyota Camry LE 2.4L (2AZFE) 4-spd (U241E)
2002 Toyota Camry LE 2.4L (2AZFE) 5-spd (E351)
2002 Toyota Camry LE 2.4L (2AZFE) 5-spd (E351)

当打开Statistics IO时，两者的输出相同：

Scan count 1, logical reads 4175, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0

Answer 1

我的查询可以使用通配符是第一个字符的索引，这对我没有意义。它不会知道B树上的行踪开始。它必须考虑表中的每一辆车，看它是否匹配。

一些可能性：

对于索引读取的六个记录，
• 300ms非常慢。我预计会更快一个数量级。你提到亚马逊。你是通过互联网链接测量的吗？如果是这样，链接速度的变化可能会干扰您的结论。
• 你总是按顺序运行它们吗？您的第二个查询可能是因为第一个查询导致数据被缓存，从而导致数据不公平。

Answer 2

至少有两种想法可能导致这种情况。

1. 用于实现谓词的CPU，内存或其他资源。这可以追溯到它们的语法不同的事实。一个是按特定顺序查找三个值，而另一个只是检查是否存在所有三个谓词
2. 带宽和其他网络瓶颈。当我们处理毫秒时，很容易采用这条路线。

此外，我会在运行缓存之前释放缓存以防止使用缓存计划。