Azure SQL执行第二个和第一个为false时的条件

我有以下问题： 当我在Azure SQL上执行查询时，第二个和条件会运行，即使第一个是false。 表项包含2048个列“Claimd”为1的项，只有一个列“Claimd”为0的项。 这一个项目也是一个项目，其中包含一个词的描述剃须刀

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

结果：经过143毫秒的时间

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

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

结果：运行时间为1毫秒

只有一个项的Claimd=0，这就解释了为什么结果会在1毫秒内显示。但是当我想搜索第二列时，使用OR条件，它就像是再次搜索整个表，而不是只搜索那些标志Claimd=0的表

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

根据文章以及其他关于堆栈溢出的答案，ANSI SQL标准没有明确保证短路

---

另一个可能的原因是[描述]上有索引，而索赔上没有索引。这也解释了为什么第二个查询要快得多——它使用了第一个查询无法使用的索引。[并不是说这是你的问题，只是它可能不知道更多关于索引和执行计划的信息]

实际上，这里没有第一个条件和第二个条件，查询优化人员将根据其当前的猜测来决定首先评估哪一个，以获得更快的答案

它将根据查询、表索引、数据类型和数据本身决定，查询优化人员通常使用从每个表中的实际数据收集的统计数据来为自己提供更多关于什么是最好的线索，例如，它知道对数据不多的表进行表扫描通常是可以的

由于查询中的任何相关列都没有索引，我的建议是在Claimd上添加索引。这对乐观主义者来说应该是一个很好的大提示，根据Claimd切割数据将是最快的解决方案。即使是最好的案例搜索，它也会提高搜索速度，不过如果搜索结果为1ms，您可能会注意到这一点

---

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

您对项目有哪些索引？仅在我的Id主键上，并且您的时间是可复制的？如果以相反的顺序运行查询，您是否看到相同的时差？可能存在缓存问题。我对Azure不太了解，有没有一种方法可以显示查询计划？另外：如果你想让它按优先顺序使用Claimd，请尝试在其上添加索引。是的，无论我运行它们的顺序如何，在两列上搜索的查询将始终在150毫秒左右可能会检查所有项目，即使Claimd=1，而只搜索一列的查询总是1-10ms。有一种方法可以查看这些计划。慢的一个需要64%的CPU时间进行过滤，而快的一个没有提到过滤