显式与隐式内部连接是否有效率差异?例如:
SELECT * FROM
table a INNER JOIN table b
ON a.id = b.id;
对比
SELECT a.*, b.*
FROM table a, table b
WHERE a.id = b.id;
在性能方面,它们完全相同(至少在 SQL Server 中)。
PS:请注意,IMPLICIT OUTER JOIN
自 SQL Server 2005 以来不推荐使用该IMPLICIT INNER JOIN
语法。(仍然支持问题中使用的语法)
就我个人而言,我更喜欢连接语法,因为它可以更清楚地说明表的连接方式以及它们的连接方式。尝试比较较大的 SQL 查询,您从 8 个不同的表中进行选择,并且您在 where 中有很多过滤。通过使用连接语法,您可以将连接表的部分与过滤行的部分分开。
在 MySQL 5.1.51 上,两个查询具有相同的执行计划:
mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| 1 | SIMPLE | b | ALL | PRIMARY | NULL | NULL | NULL | 986 | |
| 1 | SIMPLE | a | ref | pid | pid | 4 | schema.b.pid | 70 | |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)
mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| 1 | SIMPLE | b | ALL | PRIMARY | NULL | NULL | NULL | 986 | |
| 1 | SIMPLE | a | ref | pid | pid | 4 | schema.b.pid | 70 | |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)
table1
有 166208 行;table2
大约有1000行。
这是一个非常简单的案例;它无论如何都不能证明查询优化器不会混淆并在更复杂的情况下生成不同的计划。
第二种语法具有交叉连接的不希望的可能性:您可以将表添加到 FROM 部分而无需相应的 WHERE 子句。这被认为是有害的。
您给出的第一个答案使用所谓的 ANSI 连接语法,另一个是有效的并且可以在任何关系数据库中使用。
我同意 grom 的观点,即您应该使用 ANSI 连接语法。正如他们所说,主要原因是为了清晰。而不是一个 where 子句有很多谓词,其中一些连接表和其他限制使用 ANSI 连接语法返回的行,而是让您非常清楚哪些条件用于连接您的表,哪些条件用于限制结果。
@lomaxx:澄清一下,我很确定 SQL Serv 2005 支持上述两种语法。但是不支持以下语法
select a.*, b.*
from table a, table b
where a.id *= b.id;
具体来说,不支持外连接 (*=)。
性能方面,它们完全相同(至少在 SQL Server 中),但请注意,它们正在弃用这种连接语法,并且开箱即用的 sql server2005 不支持它。
我认为您正在考虑已弃用的 *= 和 =* 运算符与“外部联接”。
我刚刚测试了给定的两种格式,它们在 SQL Server 2008 数据库上正常工作。在我的例子中,它们产生了相同的执行计划,但我不能自信地说这总是正确的。
在某些数据库(尤其是 Oracle)上,连接的顺序会对查询性能产生巨大影响(如果有两个以上的表)。在一个应用程序中,在某些情况下,我们实际上有两个数量级的差异。如果您使用正确的提示语法,则使用内连接语法可以控制这一点。
您没有指定您正在使用哪个数据库,但概率建议 SQL Server 或 MySQL 在那里它没有真正的区别。
正如 Leigh Caldwell 所说,查询优化器可以根据功能上看起来像相同 SQL 语句的内容生成不同的查询计划。如需进一步阅读,请查看以下两篇博客文章:-
我希望你觉得这很有趣。
基本上,两者之间的区别在于,一个是用旧方式写的,而另一个是用现代方式写的。就个人而言,我更喜欢使用内部、左侧、外部、右侧定义的现代脚本,因为它们更具解释性并使代码更具可读性。
在处理内部连接时,可读性也没有真正的区别,但是,在处理左右连接时可能会变得复杂,因为在旧方法中你会得到如下结果:
SELECT *
FROM table a, table b
WHERE a.id = b.id (+);
以上是左连接的旧方式,而不是以下方式:
SELECT *
FROM table a
LEFT JOIN table b ON a.id = b.id;
如您所见,现代的脚本编写方式使查询更具可读性。(顺便说一句,右连接也一样,外连接稍微复杂一些)。
回到样板,它不会对 SQL 编译器如何编写查询产生影响,因为它以相同的方式处理它们。我在 Oracle 数据库中看到了这两种情况的混合,很多人都写过它,无论是年长的还是年轻的。同样,它归结为脚本的可读性和您正在开发的团队。
性能方面,它不应该有任何区别。显式连接语法对我来说似乎更清晰,因为它清楚地定义了 from 子句中的表之间的关系,并且不会弄乱 where 子句。
根据我的经验,使用 cross-join-with-a-where-clause 语法通常会产生脑残的执行计划,尤其是在您使用 Microsoft SQL 产品的情况下。例如,SQL Server 尝试估计表行数的方式非常可怕。使用内部连接语法可以让您对查询的执行方式进行一些控制。因此,从实用的角度来看,鉴于当前数据库技术的返祖性质,您必须使用内部连接。