SQL JOIN 在哪里放置 WHERE 条件？答案

【问题标题】：SQL JOIN where to place the WHERE condition?SQL JOIN 在哪里放置 WHERE 条件？
【发布时间】：2013-03-07 04:50:29
【问题描述】：

我有以下两个例子。

1.示例（WHERE）

SELECT 1
  FROM table1 t1
  JOIN table2 t2 ON t1.id = t2.id
 WHERE t2.field = true

2。示例（JOIN AND）

SELECT 1
  FROM table1 t1
  JOIN table2 t2 ON t1.id = t2.id AND t2.field = true

在性能方面更快的方法是什么？你喜欢什么？

【问题讨论】：

标签： sql join where

【解决方案1】：

如果过滤器在功能上进入JOIN 条件（即它是实际的连接条件，而不仅仅是过滤器），它必须出现在该连接的ON 子句中。

值得注意的是：

如果你把它放在WHERE子句中，如果join是INNER，性能是一样的，否则就不同。正如 cmets 中提到的，这并不重要，因为无论如何结果是不同的。
当过滤器确实是OUTER JOIN 条件时，将过滤器放在WHERE 子句中会隐式取消条件的OUTER 特性（“即使没有记录也加入”），因为这些过滤器暗示存在首先必须是现有记录。示例：

... table1 t LEFT JOIN table2 u ON ... AND t2.column = 5 是正确的

... table1 t LEFT JOIN table2 u ON ... 
WHERE t2.column = 5

不正确，因为t2.column = 5 告诉引擎来自 t2 的记录是预期的，这与外连接背道而驰。例外情况是 IS NULL 过滤器，例如 WHERE t2.column IS (NOT) NULL（这实际上是构建条件外连接的便捷方式）

LEFT 和 RIGHT 连接是隐含的 OUTER 连接。

希望对您有所帮助。

【讨论】：

这个答案包含一些错误和混乱的写作。 1. 对于 INNER JOIN，只要没有中间的 OUTER JOIN，任何条件都可以在 WHERE 而不是 ON 中。 2. 将 LEFT JOIN 条件从 ON 移动到 WHERE 时，性能无关紧要，因为（如您所说）通常结果不同。 3. 这种差异通常不会“将 OUTER JOIN 转换为 INNER JOIN”。
“过滤器在功能上进入 JOIN 条件”或“[过滤器] 是实际的连接条件，而不仅仅是过滤器”是什么意思？无论如何，“只是一个过滤器”的概念没有帮助，因为JOIN ON c AND d 的含义与JOIN ON c WHERE d 相同。（事实上，SQL 标准定义 JOIN ON 根据 JOIN WHERE。）类似地“隐式取消条件的外部性质”只是不传达任何内容。您似乎同意这一点，因为您用吓人的引号（因此本身不清楚）'（“即使没有记录也加入”）'对其进行注释。你没有解释。
PS '这些过滤器意味着必须首先存在现有记录' 不清楚，当按面值计算时不正确，'t2.column = 5 告诉引擎来自 t2 的记录是预期的，这违背了外部连接”是难以理解的。您不需要使用任何这些模糊的日常术语（可能与您的想法一致，但不要解释您的想法），只需使用适用于的技术术语对查询的各个部分及其含义进行陈述他们。
连接条件与过滤器的不同之处在于相关表中的连接条件。过滤器仅适用于一个表，例如在我编写的示例中（表 t2.column = 5）。其余的，我不敢苟同。
该评论无法解析。（但如果你编辑它，那么我希望你仍然会以模糊和不清楚的方式使用日常用词，就像已经解决的那样。例如，“过滤器”总是只适用于一个表，在 ON 的情况下是一个交叉产品，在 WHERE 的情况下是 a(n INNER or OUTER) JOIN 的结果。）（所以我希望在这里结束我的 cmets。）

【解决方案2】：

JOIN 条件通常应该独立于过滤条件。您使用ON 定义您的加入规则（如何）。您可以使用WHERE 过滤您想要的什么。在性能方面，所有引擎和设计都没有通用规则，因此您的行驶里程会有很大差异。

【讨论】：

【解决方案3】：

我认为更快的方法是将过滤器放在 where 子句中，因为它会先在 where 子句中进行过滤，然后是 join 子句，因此不需要过滤器的排列。

【讨论】：

对于经过任何优化的 DBMS 来说完全没有区别。例如，请参阅 MySQL 文档关于 SELECT/JOIN 优化：INNER JOIN 的 ON 被视为应用到该 JOIN 的 WHERE。