我注意到
FROM clause of SELECT queries中的USING结构(而不是ON)可能会在某些情况下引入优化障碍.
我的意思是这个关键词：
SELECT * FROM a JOIN b USING (a_id)
只是在更复杂的情况下.
背景：this comment至this question.
我经常使用它,到目前为止从未注意到任何事情.我会对展示效果或任何进一步信息链接的测试用例非常感兴趣.我的搜索工作空洞了.
完美答案将是一个测试用例,以显示USING(a_id)与替代连接子句ON a.a_id = b.a_id相比具有较差的性能 – 如果这实际上可能发生.
欧文：我同意这样的想法,即使用导致严格排序可能会产生许多边缘情况,在这种情况下可以排除最优计划.我最近在他的查询中帮助过那些有类似内容的人：
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行,大约20k次(算数),并且因为密钥不能被推送到索引,所以它是顺序扫描.这意味着由于级联计划更改,整个查询大约需要3个小时才能运行.通过分发左连接,可以按下键并在几秒钟内运行查询.当然,这并不完全等同,这就是为什么规划者不能将它们视为等价的原因,因此它将计划作为散列连接,然后进行嵌套循环,这非常缓慢.
每当你严格强制连接按特定顺序进行时,你会引入在执行计划时可能无法获得关键过滤器信息的情况,以及稍后在快速索引扫描/散列连接中可能做的事情可能必须在嵌套循环/顺序扫描中慢得多,因此虽然上面的片段不是立即等效的,但它显示了同样的问题.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。