Hector Scesa Asked: 2020-03-02 12:39:35 +0800 CST 2020-03-02 12:39:35 +0800 CST 2020-03-02 12:39:35 +0800 CST 隐式连接和显式连接有什么区别? 772 除了知道JOINS显式和隐式之间的区别之外,我还想知道哪些更高效、更高效? sql 1 Answers Voted Best Answer sstan 2020-03-09T11:08:42+08:002020-03-09T11:08:42+08:00 有性能差异吗? 不会。隐式或显式连接之间没有性能差异。只要它们是等效的查询,数据库引擎就会以相同的方式执行查询。(注意:有时会由于数据库引擎中的错误而出现差异。我记得在某些旧版本的 Oracle 中会发生这种情况。但实际上只是这样:最终修复了错误) 实际上,隐式连接和显式连接之间的唯一区别是语法本身。 使用一种表示法而不是另一种表示法有优势吗? 是的,使用显式连接总是更好。 原因: 因为几十年来,隐式连接语法一直被认为是过时的。 在 SQL-89 标准中,只存在隐式表示法。但是在 1992 年(25 年前!),SQL-92 引入了显式表示法。从那时起,人们普遍认为规范应该是使用新的显式表示法,尽管实际上,由于已经过去了这么长时间,它不再被认为是新的。 因为当查询比较复杂的时候,在定义连接条件的时候很容易出错。 为了更好地理解第二点,让我们以这个带有显式连接的查询为例: select a.colA, b.colB, c.colC from TableA a join TableB b on b.aid = a.id join TableC c on c.bid = b.id where a.colA like '%abc%' ...让我们使用隐式连接将它与它的等价物进行比较: select a.colA, b.colB, c.colC from TableA a, TableB b, TableC c where a.colA like '%abc%' and b.aid = a.id and c.bid = b.id 虽然这个例子非常简单,但已经可以看出显式连接表示法很好地传达了连接不同表的条件。相比之下,使用隐式表示法,这 3 个表之间的关系并不是很明显。查询越复杂,它就越不清晰和混乱。 更糟糕的是,使用隐式表示法,特别是对于更复杂的查询,很容易忘记连接条件,例如: select a.colA, b.colB, c.colC from TableA a, TableB b, TableC c where a.colA like '%abc%' and b.aid = a.id 在这个查询中,因为我们忘记了条件c.bid = b.id,我们不小心创建了一个带有 的笛卡尔计划TableC。 相比之下,由于显式连接语法,很难犯这种错误,因为对于每个连接,我们都被迫定义一个子句ON,否则查询将无法运行。 因为它是 SQL 标准中定义外连接(左连接或右连接)的唯一方法。 同样,如果我们采用以下隐式连接示例: select a.colA, b.colB, c.colC from TableA a, TableB b, TableC c where a.colA like '%abc%' and b.aid = a.id and c.bid = b.id ...但现在我们希望连接TableC是左连接而不是内连接。在各种数据库引擎中,在这种情况下,除非我们使用显式表示法,否则无法定义它。在数据库引擎有隐式表示法的情况下,该表示法不属于 SQL 标准,并且其他数据库引擎不会为您提供服务。 例如,Oracle 确实允许您使用以下方式定义左连接(+): select a.colA, b.colB, c.colC from TableA a, TableB b, TableC c where a.colA like '%abc%' and b.aid = a.id and c.bid (+) = b.id ...但这种语法仅适用于 Oracle。即使在 Oracle 中,它也被视为已弃用。此外,很容易出错,尤其是当连接条件稍微复杂一点时。 相反,如果我们使用显式符号查看左连接: select a.colA, b.colB, c.colC from TableA a join TableB b on b.aid = a.id left join TableC c on c.bid = b.id where a.colA like '%abc%' ...我们注意到,如果我们从显式表示法开始,TableC只需将其更改join为。left join它非常简单,没有更大的错误风险。
有性能差异吗?
不会。隐式或显式连接之间没有性能差异。只要它们是等效的查询,数据库引擎就会以相同的方式执行查询。(注意:有时会由于数据库引擎中的错误而出现差异。我记得在某些旧版本的 Oracle 中会发生这种情况。但实际上只是这样:最终修复了错误)
实际上,隐式连接和显式连接之间的唯一区别是语法本身。
使用一种表示法而不是另一种表示法有优势吗?
是的,使用显式连接总是更好。
原因:
在 SQL-89 标准中,只存在隐式表示法。但是在 1992 年(25 年前!),SQL-92 引入了显式表示法。从那时起,人们普遍认为规范应该是使用新的显式表示法,尽管实际上,由于已经过去了这么长时间,它不再被认为是新的。
为了更好地理解第二点,让我们以这个带有显式连接的查询为例:
...让我们使用隐式连接将它与它的等价物进行比较:
虽然这个例子非常简单,但已经可以看出显式连接表示法很好地传达了连接不同表的条件。相比之下,使用隐式表示法,这 3 个表之间的关系并不是很明显。查询越复杂,它就越不清晰和混乱。
更糟糕的是,使用隐式表示法,特别是对于更复杂的查询,很容易忘记连接条件,例如:
在这个查询中,因为我们忘记了条件
c.bid = b.id
,我们不小心创建了一个带有 的笛卡尔计划TableC
。相比之下,由于显式连接语法,很难犯这种错误,因为对于每个连接,我们都被迫定义一个子句
ON
,否则查询将无法运行。同样,如果我们采用以下隐式连接示例:
...但现在我们希望连接
TableC
是左连接而不是内连接。在各种数据库引擎中,在这种情况下,除非我们使用显式表示法,否则无法定义它。在数据库引擎有隐式表示法的情况下,该表示法不属于 SQL 标准,并且其他数据库引擎不会为您提供服务。例如,Oracle 确实允许您使用以下方式定义左连接
(+)
:...但这种语法仅适用于 Oracle。即使在 Oracle 中,它也被视为已弃用。此外,很容易出错,尤其是当连接条件稍微复杂一点时。
相反,如果我们使用显式符号查看左连接:
...我们注意到,如果我们从显式表示法开始,
TableC
只需将其更改join
为。left join
它非常简单,没有更大的错误风险。