SQL WHERE 子句是否短路评估？

Question

SQL WHERE 子句中的布尔表达式是否被短路计算 ？

例如：

SELECT * 
FROM Table t 
WHERE @key IS NULL OR (@key IS NOT NULL AND @key = t.Key) 

如果 @key IS NULL 计算结果为 true，则 @key IS NOT NULL AND @key = t.Key 是否被计算？

如果不是，为什么不呢？

如果有的话，有保证吗？ 它是 ANSI SQL 的一部分还是特定于数据库的？

如果是特定数据库，SQLServer？ 甲骨文？ MySQL？

Answer 1

ANSI SQL 草案 2003 5WD-01-Framework-2003-09.pdf

6.3.3.3 规则评估顺序

[...]

优先级不是由格式或由
括号中，表达式的有效求值通常是
从左到右执行。 然而，它是
依赖于实现表达式是否实际上是从左到右计算的，特别是当操作数或运算符可能
导致引发条件或者如果表达式的结果
无需完全评估所有部分即可确定
表达。

Answer 2

综上所述，短路实际上是不可用的。

如果您需要它，我建议使用 Case 语句：

Where Case when Expr1 then Expr2 else Expr3 end = desiredResult

始终评估 Expr1，但每行仅评估 Expr2 和 Expr3 之一。

Answer 3

我认为这是我将其写成没有短路的情况之一，原因有三个。

1. 因为对于 MSSQL，它不是通过在明显的地方查看 BOL 来解决的，所以对我来说，这使得它典型地含糊不清。

   因为对于

2. 因为至少我知道我的代码可以工作。 更重要的是，那些追随我的人也会如此，所以我不会让他们一遍又一遍地担心同一个问题。

3. 我经常为多个 DBMS 产品编写内容，如果可以轻松解决这些差异，我不想记住这些差异。

   我经常为

Answer 4

我不相信 SQL Server (2005) 中的短路是可以保证的。 SQL Server 通过其优化算法运行查询，该算法会考虑很多因素（索引、统计信息、表大小、资源等）以得出有效的执行计划。 经过这样的评估，你不能肯定地说你的短路逻辑得到了保证。

我自己不久前也遇到过同样的问题，但我的研究确实没有给我明确的答案。 您可以编写一个小查询来证明它有效，但是您可以确定随着数据库负载的增加，表变得越来越大，并且数据库中的内容得到优化和更改，该结论将抓住。 我不能，因此出于谨慎的考虑，在 WHERE 子句中使用了 CASE 来确保短路。

Answer 5

您必须记住数据库的工作原理。 给定参数化查询，数据库将基于该查询构建执行计划，而无需参数值。 每次运行查询时都会使用此查询，无论实际提供的值是什么。 查询是否与某些值短路对于执行计划并不重要。

Answer 6

我通常将其用于可选参数。 这和短路一样吗？

SELECT  [blah]
FROM    Emp
WHERE  ((@EmpID = -1) OR (@EmpID = EmpID))

这使我可以选择传递 -1 或其他值来解释属性的可选检查。 有时这涉及连接多个表，或者最好是一个视图。

非常方便，但不完全确定它给数据库引擎带来的额外工作。

Answer 7

刚刚偶然发现了这个问题，并且已经找到了这个博客条目： http://rusanu.com/2009/09/13/on-sql-server-boolean-operator-short- Circuit/

SQL Server 可以自由地在她认为合适的任何地方优化查询，因此在博客文章中给出的示例中，您不能依赖短路。

然而，显然有一个案例被记录下来以书面顺序进行评估 - 检查该博客文章的评论。

Answer 8

对于 SQL Server，我认为这取决于版本，但我对 SQL Server 2000 的经验是，即使 @key 为 null，它仍然会评估 @key = t.Key。 换句话说，它在评估 WHERE 子句时不会进行有效的短路。

我看到人们推荐像您的示例这样的结构作为进行灵活查询的方式，用户可以在其中输入或不输入各种条件。 我的观察是，当 @key 为 null 时，Key 仍然参与查询计划，并且如果 Key 已建立索引，则它不会有效地使用索引。

这种具有不同条件的灵活查询可能是动态创建 SQL 真正最佳方法的一种情况。 如果 @key 为 null，那么您根本就不将其包含在查询中。

Answer 9

短路求值的主要特点是一旦确定结果就停止对表达式求值。 这意味着表达式的其余部分可以被忽略，因为无论是否计算结果都会相同。

二元布尔运算符是可交换的，这意味着：

a AND b == b AND a
a OR  b == b OR  a
a XOR b == b XOR a

因此不能保证计算顺序。 评估顺序将由查询优化器确定。

在带有对象的语言中，有时您可以编写只能通过短路求值来求值的布尔表达式。 您的示例代码构造通常用于此类语言（C#、Delphi、VB）。 例如：

if(someString == null | someString.Length == 0 )
  printf("no text in someString");

如果 someString == null，此 C# 示例将导致异常，因为它将被完全求值。 在短路评估中，它每次都会起作用。

SQL 仅对无法初始化的标量变量（无对象）进行操作，因此无法编写无法计算的布尔表达式。 如果你有一些 NULL 值，任何比较都将返回 false。

这意味着在 SQL 中你不能编写根据使用短路或完整评估而进行不同评估的表达式。

如果 SQL 实现使用短路评估，它只能有望加快查询执行速度。

Answer 10

我不知道短路，但我也会将其写为 if-else 语句

if (@key is null)
begin

     SELECT * 
     FROM Table t 

end
else
begin

     SELECT * 
     FROM Table t 
     WHERE t.Key=@key

end

，变量应该始终位于等式的右侧。 这使得它可以被控制。

http://en.wikipedia.org/wiki/Sargable

Answer 11

下面是对 SQL Server 2008 R2 的快速而肮脏的测试：

SELECT *
FROM table
WHERE 1=0
AND (function call to complex operation)

它立即返回，没有记录。 存在某种短路行为。

然后尝试这个：

SELECT *
FROM table
WHERE (a field from table) < 0
AND (function call to complex operation)

知道没有记录会满足这个条件：

(a field from table) < 0

这花了几秒钟，表明短路行为不再存在，并且正在为每个记录评估复杂的操作。

希望这对大家有帮助。

Answer 12

下面是一个演示，证明MySQL确实执行了WHERE子句短路：

http://rextester .com/GVE4880

这将运行以下查询：

SELECT myint FROM mytable WHERE myint >= 3 OR myslowfunction('query #1', myint) = 1;
SELECT myint FROM mytable WHERE myslowfunction('query #2', myint) = 1 OR myint >= 3;

这些查询之间的唯一区别是 OR 条件中操作数的顺序。

myslowfunction 故意休眠一秒钟，并具有每次运行时向日志表添加条目的副作用。 以下是运行上述两个查询时记录的结果：

myslowfunction called for query #1 with value 1
myslowfunction called for query #1 with value 2
myslowfunction called for query #2 with value 1
myslowfunction called for query #2 with value 2
myslowfunction called for query #2 with value 3
myslowfunction called for query #2 with value 4

上面显示，当另一个操作数并不总是 true（由于短）时，慢速函数出现在 OR 条件的左侧时会执行更多次-电路）。

Answer 13

这在查询分析器中需要额外的 4 秒，所以从我所看到的 IF 甚至没有短路......

SET @ADate = NULL

IF (@ADate IS NOT NULL)
BEGIN
    INSERT INTO #ABla VALUES (1)
        (SELECT bla from a huge view)
END

如果有一个有保证的方法那就太好了！

Answer 14

它似乎是

select null 其中 1/0=0 或 1=1
-> 除以 0 失败 err

select null where 1=1 1/0=0
-> 成功

Answer 15

简单的回答是：“短路”行为是未记录的实现。
这是一篇很好的文章，解释了这个主题。

了解 T-SQL 表达式短路

Answer 16

很明显，MS Sql 服务器支持短路理论，通过避免不必要的检查来提高性能，

支持示例：

SELECT 'TEST'
WHERE 1 = 'A'

SELECT 'TEST'
WHERE 1 = 1 OR 1 = 'A'

这里，第一个示例在将 varchar 值“A”转换为数据类型 int 时会导致错误“转换失败”。 '

而第二个条件很容易运行，因为条件 1 = 1 评估为 TRUE，因此第二个条件根本不运行。

此外，

SELECT 'TEST'
WHERE 1 = 0 OR 1 = 'A'

这里第一个条件将评估为 false，因此 DBMS 将执行第二个条件，并且您将再次得到转换错误，如上例所示。

注意：我写下错误条件只是为了了解该条件是执行还是短路
如果查询结果出错，则表示条件已执行，否则为短路。

简单解释

考虑，

WHERE 1 = 1 OR 2 = 2

当第一个条件被评估为TRUE时，评估第二个条件是没有意义的，因为它的评估值是任何值
根本不会影响结果，因此 Sql Server 有机会通过跳过不必要的条件检查或评估来节省查询执行时间。

在“OR”的情况下，如果第一个条件评估为TRUE，则由“OR”连接的整个链将被视为评估为true，而不评估其他的。

condition1 OR condition2 OR ..... OR conditionN

如果条件 1 评估为真，则其余所有条件，直到条件 N 被跳过。
一般来说，在确定第一个 TRUE 时，将跳过由 OR 链接的所有其他条件。

考虑第二个条件

WHERE 1 = 0 AND 1 = 1

，因为第一个条件被评估为FALSE，评估第二个条件是没有意义的，因为它的评估值是任何值
根本不会影响结果，因此 Sql Server 再次有机会通过跳过不必要的条件检查或评估来节省查询执行时间。

在“AND”的情况下，如果第一个条件评估为FALSE，则与“AND”连接的整个链将被视为评估为FALSE，而无需评价别人。

condition1 AND condition2 AND ..... conditionN

如果条件1的计算结果为FALSE，则保留所有条件，直到条件N被跳过。
一般来说，在确定第一个FALSE时，将跳过由AND链接的所有其他条件。

因此，明智的程序员应该始终以首先评估成本较低或最具消除性的条件的方式对条件链进行编程，
或者以能够获得最大短路效益的方式安排条件