SQL查询的临时表与短路操作

下面是我想要优化的查询，这里优化的瓶颈是条件_B

select @COMPUTE_X = count(distinct TABLEA.COLUMN_T5)
from #TMP_TABLEA TABLEA
inner join TABLEB on TABLEB.ID = TABLEA.ID
left join....
where
(
  CONDITION_A --Complex condition
) and
(
  CONDITION_B --Complex condition with some functions returning table
)

如果我将上述查询的结果放入一个临时表，然后在该临时表上应用条件，我将获得非常好的性能增益。我认为条件_B总是评估条件_A的结果是否为假

---

有没有更好的方法可以告诉我。短路操作是否在SQL查询语句中起作用，如果是，它们的处理顺序是什么。

执行求值顺序的唯一方法是使用

CASE

语句。虽然它可能看起来不漂亮，但以下可能具有类似的性能：

select @COMPUTE_X = count(distinct TABLEA.COLUMN_T5)
from #TMP_TABLEA TABLEA
inner join TABLEB on TABLEB.ID = TABLEA.ID
left join....
where 1 = (CASE WHEN CONDITION_A then 1
                WHEN CONDITION_B then 1
                else 0
           end)

请记住，SQL是一种描述性语言，而不是过程性语言。您可以编写SQL来描述所需的结果。查询优化器可以完全重新安排在语句中放置内容的顺序。但是，

CASE

语句是一个例外。在大多数情况下，评估的顺序是有保证的（尽管在涉及聚合时不是这样）

---

顺便说一句，如果您发布另一个包含完整查询的查询，则可能还有其他加快查询速度的机会。

SQL不像大多数其他编程语言那样使用短路逻辑；优化器可以重新安排到它认为最好的位置。您也不能保证它不会调用第二条语句（即，

其中a不为NULL，GET_RANDOM_NUMBER（）>1

可以调用函数，而不管

a

，并且可以在查看

a

之前先调用它）。这就是说，它可以像您期望的那样运行，因为它可能能够优化掉某些东西（例如，如果

a

始终为空，并且它提前知道，它可能不会麻烦，因为条件总是错误的）。如果您提供完整的声明，以及（可能）解释计划，我们可能会更好地帮助您。你的索引是什么样子的？如果

条件

包括聚合，请小心。即使是

情况

也不能保证在所有情况下都短路。见@AaronBertrand。这是一个很好的警告。我在回答中包括了这一点。