在某些情况下，在JOIN子句中使用构造可以引入优化障碍吗？

引起我注意的是，查询子句中的USING构造（而不是ON）在某些情况下可能会引入优化障碍。FROMSELECT

我的意思是这个关键词：

选择 *
从一个
加入b 使用（a_id）

仅在更复杂的情况下。

背景：此评论到这个问题。

我用这个了很多，从来没有发现过这么远。我对一个展示效果或进一步信息的链接的测试案例非常感兴趣。我的搜索工作空虚。

USING (a_id)与替代连接子句相比，完美的答案是显示性能较差的测试用例ON a.a_id = b.a_id- 如果这确实可能发生。

欧文：我同意这样的想法，即使用USU导致严格的排序可能会在很多边缘情况下排除最佳计划。我最近帮助了在查询中遇到类似问题的人：

LEFT JOIN ( 
     a 
     JOIN b ON a.id = b.a_id
     JOIN c ON b.c_id = c.id
) ON a.id = something.a_id
LEFT JOIN (
     table1 t1
     JOIN table2 t2 ON t1.some_field = t2.other_field
     JOIN talbe3 t3 ON t2.yafield = t3.something_else
) ON ....
repeat a few more times

在他的情况下，这些连接块中最糟糕的是导致大约200k行（约2万次）的嵌套循环连接（进行数学运算），并且由于无法将键推入索引，因此这是顺序扫描。这意味着由于级联计划的更改，整个查询需要大约3个小时才能运行。通过分布左连接，可以将键按下，查询只需几秒钟即可完成。当然，这并不是完全等效的，这就是为什么计划人员无法将它们视为等效的原因，所以它只能将计划视为哈希联接，然后进行嵌套循环，这很慢。

每当您严格按一定顺序强制执行连接时，都会出现一些情况，即在执行计划时可能尚不提供关键过滤器信息，因此以后在快速索引扫描/哈希连接中可能会做些什么在嵌套循环/顺序扫描中可能必须做得慢得多，因此尽管上面的片段并不是立即等效的，但它显示了相同的问题。