隐式连接与 Postgres 中的显式连接一样有效吗？

Question

通常这样写很方便：

SELECT * 
FROM t1   # ... +many more tables
INNER JOIN t2 ON (t1.id = t2.col)
INNER JOIN t3 ON (t1.id = t3.col)
INNER JOIN t4 ON (t1.id = t4.col)
...

作为带条件的交叉连接：

SELECT * 
FROM t1, t2, t3, t4   # ... +many more tables
WHERE
       t1.id = t2.col
   AND t1.id = t3.col
   AND t1.id = t4.col
   # +include matches on columns of other tables

但是，交叉连接的简单实现将比内部连接具有更高的时间复杂度。Postgres 是否将第二个查询优化为与第一个查询具有相同时间复杂度的查询？

Answer 1

我会使用显式JOIN语法，但减少噪音：

SELECT *  -- really? *all* columns?
FROM   t1
JOIN   t2 ON t1.id = t2.col
JOIN   t3 ON t1.id = t3.col
JOIN   t4 ON t1.id = t4.col
-- ... more tables
WHERE ...

在JOIN子句中放置连接两个表的条​​件。
在WHERE子句中放置其他条件。

INNER是一个噪音词。连接条件周围不需要括号。

回答你的问题：

隐式连接与 Postgres 中的显式连接一样有效吗？

是的。效率没有区别。Postgres 通常可以自由地重新排列连接操作的顺序，并以它认为合适的任何顺序应用JOIN和WHERE条件。手册：

显式内部连接语法（INNER JOIN、CROSS JOIN或 unadorned JOIN）在语义上与在 中列出输入关系相同FROM，因此它不限制连接顺序。

OUTER此处不适用的连接有一些特殊注意事项。
并注意一些限制：

• 显式连接的绑定比隐式连接更强。这在混合两者时可能会产生副作用- 除非您了解其含义，否则应该避免这种情况。看：

• 为什么这种隐式连接的规划方式与显式连接不同？

• [FROM x, y] 在 Postgres 中是什么意思？

• 列表中有多个join_collapse_limit项目FROM（当前默认值为8），Postgres 从对最佳查询计划的详尽搜索切换到通用方法。因此，显式连接项的顺序变得更加重要——甚至具有指导意义。

既然你提到：

+更多的桌子

...您可能需要考虑如何通过仔细选择显式连接的顺序和条件的放置来优化计划时间和查询执行时间。您可能希望使用子查询、CTE、混合显式和隐式连接、在FROM子句项组之间使用括号或使用配置设置以获得最佳结果。

有关的：

• Postgres JOIN 条件与 WHERE 条件
• 在具有小 LIMIT 的外部查询中添加 ORDER BY 时，复杂视图会变慢