无论性能如何,我从下面的查询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.*
。
对于(LEFT
,RIGHT
或FULL
)OUTER
连接,是的,顺序是有意义的-和( 更新 )事情要复杂得多。
首先,外部联接不是可交换的,因此a LEFT JOIN b
与b 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_id
和c.bc_id = b.bc_id
是平等的检查,不涉及NULL
比较。
您甚至可以与其他运算符或更复杂的运算符(例如:ON a.x <= b.x
orON a.x = 7
或ON a.x LIKE b.x
or)一起使用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()完成之前将始终处于阻塞状态