Question

SELECT a, b FROM products WHERE (a = 1 OR b = 2)

...或

SELECT a, b FROM products WHERE NOT (a != 1 AND b != 2)

两种陈述都应该达到同样的效果。但是，第二个避免了SQL中臭名昭着的“OR”操作数。这会使第二个陈述更快吗？

Answer 1

传统上后者更容易让优化者处理，因为它可以轻松地将and解析为s-arg，（松散地说）是一个可以使用索引解析的谓词。

从历史上看，查询优化器无法将OR语句解析为s-args，使用OR谓词的查询无法有效地使用索引。因此，建议是避免它，并按照后一个例子重新表达查询。更新近的优化器更擅长识别适合此转换的OR语句，但复杂的OR语句仍可能使它们混淆，从而导致不必要的表扫描。

这是'OR is slow'模因的起源。性能与处理表达式的效率无关，而是优化器识别利用索引的机会的能力。

Answer 2

不，a！= 1且b！= 2与a = 1或b = 2相同。

查询优化器将为两者运行相同的查询计划，至少在Sql的任何边缘复杂的实现中都是如此。

Answer 3

SQL中没有固有的慢速或快速运算符。发出查询时，您将描述所需的结果。如果两个语义相同的查询（特别是这样的简单查询）产生非常不同的运行时间，那么SQL实现就不是很聪明。

Answer 4

SQL Server在优化之前重写所有查询，并且很可能在重写之后两个查询都是相同的。你可以在SSMS中检查他们的执行计划，只需按Ctrl + L，很可能他们会一样。

同时运行以下内容：

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

并重新运行您的查询 - 您应该看到相同的实际执行成本。

Answer 5

理想情况下，在这种情况下OR应该更快，因为对于每n个步骤，如果它已经找到a = 1那么它将不会测试第二个条件。此外，没有涉及逆运算符（NOT）。

然而，对于AND而言，SQL必须测试两个条件，因此对于每n个步骤，在OR中的其他地方评估了2n个条件，所评估的条件数总是小于2n。此外，还有一个额外的运营商需要评估。

但是，如果对a或b中的一个进行索引，则查询执行计划可能会有所不同，因为索引列比较涉及对各个比较结果集的交叉和联合连接操作!!

当你考虑使用多个表上的连接的复杂查询时，将OR视为慢运算符也是错误的，那个时候或者可能是这个问题中其他贡献者所提到的一个大问题。但对于较小的查询，OR应该没问题。事实上，每个查询都有自己的挑战，它不仅取决于帮助文件中记录的内容，还取决于数据的分布方式，重复和方差因素。