Question

我有以下问题：

当我在Azure SQL上执行查询时，第二 AND 条件会运行，即使第一个为false。
表＆＃34;项目＆＃34;包含2048个项目，其中包含“＆';声明＆＃39; = 1且仅一项声明为= 0的项目。 这一项也是具有包含单词＆＃34; razer＆＃34;。

的描述的项目

SET STATISTICS TIME on
SELECT * FROM dbo.Items
WHERE Claimd=0 AND
([Description] LIKE '%razer%' OR [Name] LIKE '%razer%')

结果：已用时间 143 ms

如果我只是搜索描述，我会得到以下结果：

SET STATISTICS TIME on
SELECT * FROM dbo.Items
WHERE Claimd=0 AND
[Description] LIKE '%razer%'

结果：经过时间 1 ms

只有一个项目的声明= 0，因此可以解释为什么结果会在1毫秒内显示。但是当我想要搜索第二列时，使用OR条件，就像它再次搜索整个表格而不是只搜索带有标记的那些＃34;声称＆＃34; = 0 < / p>

我的括号有问题吗？我真的想知道为什么在添加OR语句时第二个AND语句正在执行，即使第一个语句为false。

Answer 1

根据this文章以及Stack Overflow here和here的其他答案，ANSI SQL标准没有明确保证短路。

您的时间差异的另一个可能原因可能是[Description]上的索引，Claimd上没有。这也可以解释为什么第二个查询更快 - 它使用的是第一个查询不能的索引。 [不是说是你的问题，只是它可能在不了解索引和执行计划的情况下更多]

Answer 2

实际上，没有＆＃34;第一个条件＆＃34;和＆＃34;第二个条件＆＃34;在这里 - 查询优化器将根据当前的猜测决定首先评估哪个将给出更快的答案。

它将根据查询，表索引，数据类型和数据本身来决定（查询优化器通常使用从每个表中的实际数据收集的统计信息，为自己提供更多关于＆＃的线索39;最好，例如，它知道对没有太多数据的表的表扫描通常是可以的。）

由于您没有查询查询中任何相关列的索引，我的建议只是在Claimd上添加索引。对于优化者来说，这应该是一个很好的大提示，即根据Claimd切割数据将是最快的解决方案。它还应该提高你最好的情况下的速度＆＃34;搜索，虽然已经有1ms的结果，但您可能会注意到这一点。

根据您对正在运行的查询的了解添加索引以及列中值的可能分布通常是一件好事，但要注意不要过早优化。如果143ms实际上没有造成问题，那么它可能永远不会导致问题：随着更多数据被添加到表中，查询优化器可能已将其策略更改为至少在Claimd上进行表扫描首先是在所有情况下。查询优化器是一种难以理解的动物。