Question

我正在学习自我加入，我注意到有两种说法：

-- use from ... where .... like cartesian
select e1.name as employee, e2.name as manager
from emp e1, emp e2
where e1.emp_id = e2.manager_id

-- use join ... on ...
select e1.name as employee, e2.name as manager
from emp e1 join emp e2
on e1.emp_id = e2.manager_id

我注意到计划时间和执行时间几乎相同，这是否意味着两种方法都相似，我可以选择什么？是否需要权衡选择一个而不是另一个？

由于

Answer 1

在查询中定义关系时，总是使用join：这样，您就可以清晰有序地保持关系和条件的分离。

＆＃34;保留订单，订单会让您保持＆＃34;

JOIN用于定义您正在为之工作的数据集的域名时，WHERE用于获取您所在域的子集时使用的SELECT已经定义了。我在编写有关SQL FROM语句执行顺序的查询时所做的快速检查列表是：

INNER JOIN

WHERE



GROUP BY

HAVING（和汇总）

ORDER BY

SELECT和where

（是的，我知道这很简单，但它对我很有帮助）。这样我就可以保持秩序：首先，我必须定义我的数据集的源，其中包括我可能需要的任何关系。之后，我可以过滤我的数据集以满足我的需求，然后我可以对其进行转换。只有这样我才能看到我的数据。

请考虑以下示例（使用select e1.name as employee, e2.name as manager from emp e1, emp e2 where e1.emp_id = e2.manager_id and e1.departament = 'Sales' -- When you add conditions to the query things can be -- confusing: Where the 'relations' end and the 'conditions' -- begin?方法）：

join

现在，使用select e1.name as employee, e2.name as manager from emp e1 inner join emp e2 on e1.emp_id = e2.manager_id -- Relations are clearly where e1.departament = 'Sales' -- separated, and you can focus -- on filter conditions in the -- WHERE clause：

考虑相同的示例

WHERE

另一个例子：如果你需要使用多个表怎么办？如果您使用隐式关系（即在OUTER JOIN子句中定义关系），您很快就会感到困惑。如果您需要定义JOIN s？

，该怎么办？

底线：始终使用Event::fake()：它会帮助您

Answer 2

是的，你可以选择任何东西。两种方式都没有错。没有规则您应该使用JOIN并且没有警察强制执行它。然而有些人认为他们必须制定这些规则并成为警察。

那说，有差异。将连接条件放在where子句中有点过时了。使用JOIN和ON可能会更有条理，但另一种方式并非令人眼花缭乱。当您使用外连接时，语法更清晰，对于不同的数据库更加相同。

最重要的区别是：使用ON时，您可以在执行连接之前对表执行的ON子句添加限制，这可以显着提高绩效。例如：

SELECT e1.name as manager, e2.name as employee FROM emp e1 JOIN emp e2 -- INNER is implicit ON e1.emp_id = e2.manager_id AND e2.department = 'Sales'

自我JOIN的SQL性能

2 个答案: