看似不正确的运算符优先级

Question

我在理解某些运算符优先级时遇到了一些困难，我预计下面的 所有 查询都会失败；这是基于下面的文档，其中将在比较运算符之前评估除法。

t-sql 运算符优先级的 Microsoft 文档：https://docs.microsoft.com/en-us/sql/t-sql/language-elements/operator-precedence-transact-sql?view=sql-server-2017

示例数据和查询

CREATE TABLE #orders(
    price INT
)
GO 

INSERT INTO #orders VALUES 
(1)
,(2)
,(3)
,(4)
,(5)
,(6)
,(7)
,(8)
,(9)
,(10)
,(0)  

GO

/*
the following two queries work
*/
SELECT * 
FROM   #orders 
WHERE  2 / price > 0 
       AND price > 0; 

SELECT * 
FROM   #orders 
WHERE  price > 0 
       AND 2 / price > 0; 

/*
these don't work - getting divide by zero error
*/
SELECT * 
FROM   #orders 
WHERE  2 / price > 0 
       AND price IN ( 1, 2, 3, 4, 
                      5, 6, 7, 8, 
                      9, 10 ); 

SELECT * 
FROM   #orders 
WHERE  price IN ( 1, 2, 3, 4, 
                  5, 6, 7, 8, 
                  9, 10 ) 
       AND 2 / price > 0; 

其中一个工作查询的共享执行计划：https://www.brentozar.com/pastetheplan/?id=HJFH3JWB7

其中一个非工作查询的共享（估计）执行计划：https://www.brentozar.com/pastetheplan/?id=r1Ds2yWSQ

任何帮助理解这种行为将不胜感激！

谢谢，

伊莱

Answer 1

好问题。我认为documentation page that you shared 上的语言可能有点不精确，这可能会导致您的困惑。这是一个引用（强调我的）：

当复杂表达式有多个运算符时，运算符优先级 确定执行操作的顺序。这 执行顺序会显着影响结果值。

这里的强烈暗示是优先级和执行顺序本质上是相同的，但它们不是。 Eric Lippert explains this 比以往任何时候都好（强调原文）。

Precedence 规则描述了带括号的表达式应该如何 当表达式混合不同种类的 运营商。例如，乘法的优先级高于 另外，所以 2 + 3 x 4 等价于 2 + (3 x 4)，而不是 (2 + 3) x 4。

关联性规则描述了括号不足的表达式 当表达式有一堆相同的时候应该用括号括起来 一种运算符。例如，加法是从左到 对，所以 a + b + c 等价于 (a + b) + c，而不是 a + (b + c)。在 普通算术，这两个表达式总是给出相同的 结果;在计算机算术中，它们不一定。 （作为一个 练习你能找到 a、b、c 的值，使得 (a + b) + c 是 不等于 C# 中的 a + (b + c)？）

现在是令人困惑的一个。

求值顺序规则描述了每个操作数在 评估一个表达式。括号只是描述如何 结果被组合在一起； “先做括号”不是规则 C# 的。相反，C# 中的规则是“严格评估每个子表达式 从左到右”。

阅读全文。 Eric 使用 C# 和 C++ 作为他的示例，但他的 cmets 的应用范围更广。正如他所建议的那样，如果您将运算符优先规则视为控制表达式组件的分组方式而不是它们的执行顺序，那么您所看到的行为就更有意义了。这是您可以理解地预期会失败但实际上成功的查询之一的简化​​版本：

declare @t table (x int);
insert @t values (0);

select * from @t where 2 / x > 0 and x > 0;

SQL Server 的运算符优先级规则简单来说就是上面的查询等价于：

-- Same query as above with operator precedence shown explicitly.
select * from @t where ((2 / x) > 0) and (x > 0);

在这种情况下，AND 的有趣之处在于，如果您知道它的一个操作数为假，那么您甚至无需计算另一个操作数就知道整个表达式为假。一些编程语言指定了操作数求值发生的顺序。例如，the && operator in C# 首先计算其左侧操作数，如果为假，则根本不计算其右侧操作数。但是AND operator in T-SQL 没有以任何方式提出任何要求；由优化器选择。

已经有很多文章专门详细探讨了这种行为；例如，here is a pretty detailed one。这有帮助吗？

Answer 2

我认为这与运算符优先级无关，而是与优化器选择评估 where 子句的顺序有关。

在前两个中，必须过滤行where price > 0首先防止错误。

由于后两个使用IN，因此必须首先进行除以限制行，然后评估IN 过滤器。这可以通过添加索引来防止......即使ID成为主键，这将创建一个聚集索引，并且您不会收到错误，因为优化器可以在除法之前使用索引并过滤行，或者选择。

谓词应从price > 0 AND 2 / price > 0 更改为2/price > 0

Answer 3

实际上，我的偏好是更改表达式（您不太可能拥有价格指数 - 或者只是使其具有或不具有指数的稳健性）：

SELECT * 
FROM   #orders 
WHERE CASE WHEN price > 0 THEN 2/price ELSE 0 END > 0 AND
      price IN ( 1, 2, 3, 4, 
                  5, 6, 7, 8, 
                  9, 10 );