当前位置：文江博客话题详情

SQL OR 和 AND 运算符的行为

发布于 2024-10-18 03:35:39 字数 196 浏览 6 评论 0原文

我们有以下表达式作为 T-Sql 查询：

Exp1 OR Exp2

当 Exp1 为 True 时，是否计算 Exp2？我认为没有必要去评价。

相似地;例如，

当 Exp1 为 false 时， Exp1 AND Exp2

是否计算 Exp2？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

半城柳色半声笛 2024-10-25 03:35:39

与某些编程语言不同，您无法计数关于 T-SQL WHERE短路 > 条款。这可能会发生，也可能会发生不是。

回复收藏 0 原文

唯憾梦倾城 2024-10-25 03:35:39

SQL Server 不一定按从左到右的顺序计算表达式。评估顺序由执行计划控制，并且根据整个查询的总体估计成本来选择计划。因此，不能确定 SQL 是否会执行您所描述的那种短路优化。这种灵活性使得优化器变得有用。例如，每种情况下的第二个表达式可能比第一个表达式更有效地计算（例如，如果它被索引或受到某些约束）。

SQL 还使用三值逻辑，这意味着二值逻辑中使用的一些等价规则不适用（尽管这不会改变您描述的具体示例）。

回复收藏 0 原文

黄昏下泛黄的笔记 2024-10-25 03:35:39

SQL Server 查询运算符 OR 和 AND 是可交换的。没有固有的顺序，查询优化器可以自由选择成本最低的路径来开始评估。一旦计划确定，如果结果是预先确定的，则不评估其他部分。

查询。

select * from master..spt_values
where (type = 'P' or 1=@param1)
  and (1=@param2 or number < 1000)
option (recompile)

这些知识允许像当 @param 设置为 1 时评估模式保证短路这样的这种模式是可选过滤器的典型模式。请注意，@params 是在其他部分之前还是之后测试并不重要。

如果您非常擅长 SQL，并且知道查询最好强制执行某个计划，那么您可以使用 CASE 语句来玩弄 SQL Server，这些语句始终按嵌套顺序进行计算。下面的示例将强制首先评估 type='P' 始终。

select *
from master..spt_values
where
    case when type='P' then
        case when number < 100 then 1
    end end = 1

如果您不相信最后一个查询的求值顺序，请尝试这个

select *
from master..spt_values
where
    case when type='P' then
        case when number < 0 then
            case when 1/0=1 then 1
    end end end = 1

即使表达式 1/0=1 中的常量是求值成本最低的，但它永远不会求值 - 否则查询会导致被零除而不是返回任何行（master..spt_values 中没有行匹配这两个条件）。

SQL Server query operators OR and AND are commutative. There is no inherent order and the query optimizer is free to choose the path of least cost to begin evaluation. Once the plan is set, the other part is not evaluated if a result is pre-determined.

This knowledge allows queries like

select * from master..spt_values
where (type = 'P' or 1=@param1)
  and (1=@param2 or number < 1000)
option (recompile)

Where the pattern of evaluation is guaranteed to short circuit when @param is set to 1. This pattern is typical of optional filters. Notice that it does not matter whether the @params are tested before or after the other part.

If you are very good with SQL and know for a fact that the query is best forced down a certain plan, you can game SQL Server using CASE statements, which are always evaluated in nested order. Example below will force type='P' to always be evaluated first.

select *
from master..spt_values
where
    case when type='P' then
        case when number < 100 then 1
    end end = 1

If you don't believe order of evaluation of the last query, try this

select *
from master..spt_values
where
    case when type='P' then
        case when number < 0 then
            case when 1/0=1 then 1
    end end end = 1

Even though the constants in the expression 1/0=1 is the least cost to evaluate, it is NEVER evaluated - otherwise the query would have resulted in divide-by-zero instead of returning no rows (there are no rows in master..spt_values matching both conditions).

回复收藏 0 原文