当使用左(外)连接时,连接中表的顺序重要吗?
我想确认 SQL 查询
SELECT ....
FROM apples,
oranges
LEFT JOIN kiwis ON kiwis.orange_id = oranges.id,
bananas
WHERE ....
与 FROM 子条款中的其他排列完全相同,例如
SELECT ....
FROM oranges
LEFT JOIN kiwis ON kiwis.orange_id = oranges.id,
bananas,
apples
WHERE ....
or
SELECT ....
FROM bananas,
apples,
oranges
LEFT JOIN kiwis ON kiwis.orange_id = oranges.id
WHERE ....
只要橙子和猕猴桃之间的显式 LEFT JOIN 保持不变。从我在各种文档中读到的内容来看,返回的集合应该完全相同。
我实际上只关心查询的结果,而不关心它在实际数据库中的性能。 (我使用的是 PostgreSQL 8.3,据我所知,它不支持有关连接顺序的优化器提示,并且会尝试自动创建最佳查询计划)。
I would like to confirm that the SQL query
SELECT ....
FROM apples,
oranges
LEFT JOIN kiwis ON kiwis.orange_id = oranges.id,
bananas
WHERE ....
is exactly equivalent to other permutations in the FROM subclause, like
SELECT ....
FROM oranges
LEFT JOIN kiwis ON kiwis.orange_id = oranges.id,
bananas,
apples
WHERE ....
or
SELECT ....
FROM bananas,
apples,
oranges
LEFT JOIN kiwis ON kiwis.orange_id = oranges.id
WHERE ....
as long as the explicit LEFT JOIN between oranges and kiwis remains intact. From what I've read in various documents, the returned set should be exactly the same.
I'm really only concerned with the results of the query, not its performance in an actual database. (I'm using PostgreSQL 8.3, which AFAIK doesn't support optimizer hints about the join order, and will try to create an optimal query plan automatically).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
它是相同的,但是对于隐式 CROSS JOIN 来说它是非常模糊的。使用显式联接。
如果您在 WHERE 子句中进行联接,则结果可能会有所不同,因为联接和过滤器被混淆了。
注意:
It is the same but it is ambiguous as hell with the implicit CROSS JOINs. Use explicit JOINS.
If you are joining in the WHERE clause then the results may differ because joins and filters are mixed up.
Notes:
使用显式 JOIN 子句控制规划器中总结了这种情况。外部联接不会重新排序,内部联接可以。您可以通过在运行查询之前删除 *join_collapse_limit* 来强制执行特定的优化器顺序,然后按照您想要的顺序放置内容。这就是您在该区域中“暗示”数据库的方式。
一般来说,您希望使用 EXPLAIN 来确认您获得的顺序,有时可以使用它来直观地确认两个查询正在获得相同的计划。
The situation is summarized at Controlling the Planner with Explicit JOIN Clauses. Outer joins don't get reordered, inner ones can be. And you can force a particular optimizer order by dropping *join_collapse_limit* before running the query, and just putting things in the order you want them it. That's how you "hint" at the database in this area.
In general, you want to use EXPLAIN to confirm what order you're getting, and that can sometimes be used to visually confirm that two queries are getting the same plan.
我已经做了很多年的 SQL,根据我的所有经验,表顺序并不重要。数据库会将查询视为一个整体并创建最佳查询计划。这就是数据库公司雇用许多拥有博士学位的人员从事查询计划优化的原因。
如果数据库供应商按照您个人在查询中列出的 SQL 的顺序进行优化,那么它就会在商业上自杀。
I've done SQL for donkeys years, and in all my experience, the table order does not matter. The database will look at the query as a whole and create the optimal query plan. That is why database companies employ many people with PhD in query plan optimisations.
The database vendor would commit commercial suicide if it optimised by the order in which you personally listed the SQL in your query.