sql-server - WHERE 子句最好在 IN 和 JOIN 之前或之后执行

Question

我读过这篇文章: Logical Processing Order of the SELECT statement

在文章末尾已经写了 ON 和 JOIN 子句考虑在 WHERE 之前。

假设我们有一个包含 1000 万条记录的主表和一个包含 5000 万条记录的明细表(引用主表(FK))。我们有一个查询，根据主表中的 PK，只需要明细表的 100 条记录。

在这种情况下，ON和JOIN先于WHERE执行？我的意思是我们在JOIN之后有5亿条记录，然后在WHERE应用它？还是先WHERE应用，然后JOIN和ON考虑？如果第二个答案为真，它与顶级文章不一致吗？

谢谢

Answer 1

对于 INNER JOIN 或 LEFT JOIN 中左侧的表，在许多情况下，优化器会发现最好在实际执行任何类型的物理连接之前先执行任何过滤(最高选择性) - 所以显然有更好的物理操作顺序。

在某种程度上，有时您可以使用 SQL 来控制(或干扰)这一点，例如，使用子查询中的聚合。

处理查询中约束的逻辑顺序只能根据已知的不变变换进行变换。

所以:

SELECT *
FROM a
INNER JOIN b
    ON a.id = b.id
WHERE a.something = something
    AND b.something = something

在逻辑上仍然等同于:

SELECT *
FROM a
INNER JOIN b
    ON a.id = b.id
    AND a.something = something
    AND b.something = something

他们通常会有相同的执行计划。

另一方面:

SELECT *
FROM a
LEFT JOIN b
    ON a.id = b.id
WHERE a.something = something
    AND b.something = something

不等于:

SELECT *
FROM a
LEFT JOIN b
    ON a.id = b.id
    AND a.something = something
    AND b.something = something

因此优化器不会将它们转换为相同的执行计划。

优化器非常智能，能够非常成功地移动事物，包括折叠 View 和内联表值函数，甚至可以相当成功地通过某些类型的聚合将事物向下推送。

通常，当您编写 SQL 时，它需要易于理解、可维护且正确。就执行效率而言，如果优化器难以将声明式 SQL 转换为性能可接受的执行计划，有时可以简化代码，或者添加适当的索引或提示，或者将其分解为应该 执行速度更快 - 所有这些都按照连续的侵入顺序进行。