当前位置: 首页 > 面试题库 >

联接顺序在SQL中重要吗?

龚德本
2023-03-14
问题内容

无论性能如何,我从下面的查询A和B中都能得到相同的结果吗?C和D呢?

-- A
select *
from   a left join b
           on <blahblah>
       left join c
           on <blahblan>


-- B
select *
from   a left join c
           on <blahblah>
       left join b
           on <blahblan>

-- C
select *
from   a join b
           on <blahblah>
       join c
           on <blahblan>


-- D
select *
from   a join c
           on <blahblah>
       join b
           on <blahblan>

问题答案:

对于INNER联接,不,顺序无关紧要。该查询将返回相同的结果,只要你改变你的选择SELECT *SELECT a.*, b.*, c.*

对于(LEFTRIGHTFULLOUTER连接,是的,顺序是有意义的-和( 更新 )事情要复杂得多。

首先,外部联接不是可交换的,因此a LEFT JOIN bb LEFT JOIN a

外部联接也不是关联的,因此在您的示例中同时涉及(可交换性和关联性)两个属性:

a LEFT JOIN b 
    ON b.ab_id = a.ab_id
  LEFT JOIN c
    ON c.ac_id = a.ac_id

等效于

a LEFT JOIN c 
    ON c.ac_id = a.ac_id
  LEFT JOIN b
    ON b.ab_id = a.ab_id

但:

a LEFT JOIN b 
    ON  b.ab_id = a.ab_id
  LEFT JOIN c
    ON  c.ac_id = a.ac_id
    AND c.bc_id = b.bc_id

不等同于

a LEFT JOIN c 
    ON  c.ac_id = a.ac_id
  LEFT JOIN b
    ON  b.ab_id = a.ab_id
    AND b.bc_id = c.bc_id

另一个(希望更简单)的关联示例。认为是(a LEFT JOIN b) LEFT JOIN c

a LEFT JOIN b 
    ON b.ab_id = a.ab_id          -- AB condition
 LEFT JOIN c
    ON c.bc_id = b.bc_id          -- BC condition

等效a LEFT JOIN (b LEFT JOIN c)

a LEFT JOIN  
    b LEFT JOIN c
        ON c.bc_id = b.bc_id          -- BC condition
    ON b.ab_id = a.ab_id          -- AB condition

仅因为我们有“好”的ON条件。这两个ON b.ab_id = a.ab_idc.bc_id = b.bc_id是平等的检查,不涉及NULL比较。

您甚至可以与其他运算符或更复杂的运算符(例如:ON a.x <= b.xorON a.x = 7ON a.x LIKE b.xor)一起使用ON (a.x, a.y) = (b.x, b.y),两个查询仍然相等。

但是,如果其中任何一个涉及到IS NULL或与空值有关的函数COALESCE()(例如,如果条件为)b.ab_id IS NULL,则这两个查询将是不相等的。



 类似资料:
  • 问题内容: 在我的办公室里,关于sql联接中联接列的顺序正在进行很大的讨论。我很难解释它,所以我只介绍两个sql语句。考虑到sql最佳实践,哪个更好? 或者 因此,在联接的ON部分中,是否编写是否重要? 问题答案: 此处的最佳实践是选择一个并 在团队中 坚持使用。就我个人而言,我更喜欢它,因为它对我来说似乎更干净。

  • 问题内容: 我想确认SQL查询 完全等同于FROM子句中的其他排列,例如 或者 只要橙子和奇异果之间的显式LEFT JOIN保持不变即可。根据我在各种文档中所阅读的内容,返回的集合应该完全相同。 我真的只关心查询的结果,而不关心它在实际数据库中的性能。(我使用的是PostgreSQL 8.3,而AFAIK不支持有关连接顺序的优化程序提示,它将尝试自动创建最佳查询计划)。 问题答案: 它是相同的,但

  • 问题内容: 我有一个查询,其中Where子句中包含三个内部join语句。该查询大约需要2分钟才能执行。如果仅更改两个内部联接的顺序,性能将下降到40秒。 除了更改内部联接的顺序外,什么都不做会对查询性能产生如此大的影响?我本以为优化器会解决所有这些问题。 问题答案: SQL是声明性的,也就是说,JOIN顺序无关紧要。 但是,实际上,如果优化器未探究所有选项(理论上可能要花费数月),这是否是一个复杂

  • 问题内容: 我正在使用PHP生成需要以自定义方式排序的SQL查询。我正在生成一个带有多个分配数字排名的语句的块。包含的语句取决于我可以查询多少信息。例如,如果我有一部电话,我将生成三个语句: 因此,我根据匹配的接近程度进行排名,并且对参数进行相同的评估(电话,名字和姓氏的匹配项应与地址,名字和姓氏的匹配项位于同一层)。但是,在为多条信息(电话,地址等)生成这些语句之后,我的语句将全部乱七八糟。该封

  • 问题内容: 从MySQL表中选择列时,与列在表中的顺序相比,选择列的顺序是否会影响性能(不考虑可能覆盖列的索引)? 例如,您有一个表,其中包含uid,name,bday行,并具有以下查询。 MySQL是否会以不同的方式看到以下查询,从而导致性能下降? 问题答案: 实际上,顺序并不重要,因此您可以随意随意订购。 编辑:我想更多的背景是有帮助的:据我所知,优化任何查询的过程发生在确切确定要提取行数据的

  • 假设我们扩展了一个名为<code>MyRecursiveTask。 然后在 forkJoinTask 的范围内创建两个子任务: 我认为“t2”将位于工作队列的顶部(这是一个deque,它被用作worker本身的堆栈),因为我看到fork方法的实现如下: 如果是,以下两个表达式的性能是否存在差异: 表达式1: 表达式 2: 我认为这可能很重要在<code>t2.join()完成之前将始终处于阻塞状态