Sql server SQL Server是否会使IF语句短路？

我正在优化一些频繁使用的存储过程，遇到了一个场景，它提出了一个我找不到任何答案的问题：在存储过程中评估TSQL时，SQL Server是否会使

IF

语句短路

例如，假设存储过程的代码类似于：

IF @condition1 = 1
OR EXISTS(SELECT 1 FROM table1 WHERE column1 = @value1)
...

在这种情况下，SQL Server是否会使求值短路，从而在前面的子句求值为true时，永远不会执行

EXISTS

语句

---

如果它从来没有或者只是偶尔有，那么我们前面就有一些重写。

好消息是它似乎短路了。下面是一个简单的例子：

DECLARE @condition1 bit = 1

IF (@condition1 = 1) OR EXISTS(SELECT 1 FROM sys.objects)
    PRINT 'True'
ELSE
    PRINT 'False'

当

@条件设置为1时，这是执行计划：从
系统对象扫描0行


当
@条件
设置为0时，它扫描
系统对象
表：


但不能保证每次都是这样。
即使它看起来有效，也不应该依赖它。该声明是文档中唯一声明为短路的内容，但即使如此（或至少不是）也并非总是如此（嘻嘻）。幸运的是，在SQLServer2012中修复了一个（请参见注释）

除了@Martin就这个问题发表的评论中的兔子洞（当然是一个有趣的链接）外，你还应该看看这篇文章：


与该文章相关的讨论论坛。
不保证。检查执行计划，看看它是否在你的情况下。谢谢，“不保证”是我要找的。问题是，这些存储过程在数百个客户数据库上执行，因此如果执行计划确定了这一点，我们不能假设在每个客户的系统上都会对其进行相同的评估，并且需要重写。如果您想要铁一般的保证，则将其分离为多个
if
语句即可。当我发现一些例子，它不是短路。您还可以研究如何使用case语句。@MartinSmith:这是一个非常好的信息，我非常喜欢case语句的方法。这个问题似乎是问在查询之外是否发生短路。我看到的所有答案和链接都是关于查询案例内部的。我想在这种特殊情况下，短路确实会发生，而且是有保证的，但我不知道。是否有人能解决短路是否发生在查询之外的语句中（即，它不是在Where子句之类的语句中）的问题？