就优化器而言，使用ON或WHERE定义连接子句应该没有区别。

然而，恕我直言，我认为在执行连接时使用ON子句更清楚。这样，您就有了查询的特定部分，该部分规定了如何处理连接，而不是与其余WHERE子句混合。

对于内部连接，WHERE和ON可以互换使用。事实上，可以在相关子查询中使用ON。例如:

update mytable
set myscore=100
where exists (
select 1 from table1
inner join table2
on (table2.key = mytable.key)
inner join table3
on (table3.key = table2.key and table3.key = table1.key)
...
)

这(恕我直言)完全让人困惑，而且很容易忘记将table1链接到任何东西(因为“driver”表没有“on”子句)，但这是合法的。

a. WHERE子句:加入后，记录将被过滤。

b. ON子句-在加入之前，记录(来自右边表格)将被过滤。

为了补充Joel Coehoorn的回答，我将添加一些特定于sqlite的优化信息(其他SQL风格的行为可能不同)。在原来的例子中，LEFT JOIN有不同的结果，这取决于你是否使用JOIN on…在哪里或加入…和。下面是一个稍微修改过的例子:

SELECT *
FROM Orders
LEFT JOIN OrderLines ON Orders.ID = OrderLines.OrderID
    WHERE Orders.Username = OrderLines.Username

与

SELECT *
FROM Orders
LEFT JOIN OrderLines ON Orders.ID = OrderLines.OrderID 
    AND Orders.Username = OrderLines.Username

现在，最初的答案指出，如果使用普通的内部连接而不是左连接，两个查询的结果将是相同的，但执行计划将有所不同。我最近意识到，两者之间的语义差异是，前者强制查询优化器使用与ON子句关联的索引，而后者允许优化器选择ON子句中的任何索引……AND子句，这取决于它认为最有效的方式。

有时，优化器会猜错，您会想强制执行某个执行计划。在本例中，假设SQLite优化器错误地得出结论，认为执行此连接的最快方法是使用Orders上的索引。用户名，当您从经验测试中知道，对订单的索引。ID可以更快地传递查询。

在这种情况下，前者JOIN ON…WHERE语法实际上允许您强制对ID参数执行主连接操作，只有在主连接完成之后才对Username执行辅助过滤。相反，JOIN ON…AND语法允许优化器选择是否在Orders上使用索引。ID或订单。用户名，理论上有可能它会选择一个速度较慢的。

这就是我的解。

SELECT song_ID,songs.fullname, singers.fullname
FROM music JOIN songs ON songs.ID = music.song_ID  
JOIN singers ON singers.ID = music.singer_ID
GROUP BY songs.fullname

你必须有GROUP BY才能让它工作。

希望这对你有所帮助。

从字面上看，它们是等价的。

在大多数开源数据库(最著名的例子是MySql和postgresql)中，查询计划是出现在关系数据库管理系统中的访问路径选择(Selinger et al, 1979)中的经典算法的变体。在这种方法中，条件有两种类型

引用单个表的条件(用于筛选) 引用两个表的条件(不管它们出现在哪里，都被视为连接条件)

特别是在MySql中，通过跟踪优化器，您可以看到自己的join ..On条件在解析过程中被等价的where条件替换。类似的事情也发生在postgresql中(虽然没有办法通过日志看到它，你必须阅读源代码描述)。

无论如何，主要的一点是，这两种语法变体之间的差异在解析/查询-重写阶段就消失了，甚至没有达到查询计划和执行阶段。因此，就性能而言，它们是否相同是毫无疑问的，它们在进入执行阶段之前就已经完全相同了。

你可以用explain来验证他们的计划是否相同。例如，在postgres中，计划将包含一个join子句，即使你没有在语法中使用join..on。

Oracle和SQL server不是开源的，但是，据我所知，它们基于等价规则(类似于关系代数中的规则)，并且它们在这两种情况下也产生相同的执行计划。

显然，对于外部连接，这两种语法风格是不相等的，对于那些你必须使用join…在语法