三表做left jion时的连接顺序与执行时长

[qhd2004]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
oltp环境

【概述】 场景 + 问题概述
三张表做left jion查询，两种写法执行时长差太多了，如下：

这里查询是0.02秒

这里是4.58秒

这里我想问一下，如果是三表left jion，是怎么个连接顺序？
0.02秒那个查询是，先OrderHisASs与CustomerInfoHis AS s1联合查询，然后把结果再与ProductInfoHisASs0`联合吗？

4.58秒那个查询是，先OrderHisASs与ProductInfoHis AS s0联合查询，然后把结果再与CustomerInfoHisASs1`联合吗？

是联合顺序是跟在from子句中出现的先后有关吗？如果4表呢
from a
left jion b
left jion c
left jion d
那是先a与b先联合，结果为s1，然后把s1与c联合，结果为s2，再把s2与d联合，这样的顺序执行吗？

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】
v5.2.2

【应用软件及版本】

【附件】 相关日志及配置信息

• TiUP Cluster Display 信息
• TiUP CLuster Edit config 信息

监控（https://metricstool.pingcap.com/)

• TiDB-Overview Grafana监控
• TiDB Grafana 监控
• TiKV Grafana 监控
• PD Grafana 监控
• 对应模块日志（包含问题前后 1 小时日志）

---

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[h5n1]

优化器问题，确实会出现表顺序影响关联顺序情况，先analyze table 保持统计信息最新，看看不同顺序是否会保持相同计划，

[dba_wxm]

兄弟， 我也遇到过这种情况， 是不是 5.4.0的优化器不稳定？？？
具体看我帖子

TIDB 5.4.0 使用 limit 爆内存oom ， 不使用 limit 则可以查询出结果

analyze table是让统计信息是最新的 期望优化器能根据统计信息选出执行计划，如果可以的话可以用SPM绑定执行计划，就不需要修改代码了

[dba_wxm]

我试验的结果是 保持统计信息最新，也不能保持相同的计划，而且计划不稳定，会变化好几种

[h5n1]

试试看有哪些hint可以用，用SPM绑定下

[Hacker_ZcrkjsVg]

这种多表关联的hint 怎么写呢 有例子吗 案例太少了

[h5n1]

试试join类提示

[qhd2004]

我在mysql中测试了一下，这两种写法是同一个执行计划

[h5n1]

tidb上重新收集统计信息后试过吗

[wisdom]

你看一下tidb的统计信息 是不是不是最新的 或者看一下执行计划 看一下 它是怎么执行的 看看它怎么选择的

[疾风之狼]

一般来说不要过于依赖优化器的优化，写SQL的时候，依据从左至右的规则来连接就行。这个是很重要的。优化器做得好的，也就Oracle。

[张雨齐0720 (Zhangjig)]

统计信息会影响连接表时，哪个表做驱动表，影响执行效率的

[windyzhousir]

left join写法下，大部分都已经是指定关联顺序。优化器能做的，只是当你过滤条件满足做内连接跟做左连接结果等价时，才会把这两表的连接重写成内连接，这种情况下才可能调整顺序。

[qhd2004]

其实我更倾向于认为是优化器的bug

[qhd2004]

感谢大家热情答复，本帖长期有效，欢迎大家对表连接或是优化器的感想写到本帖中。

[spc_monkey (carry@pingcap.com)]

建议 i标记一下，低版本，这个问题还是很多人都会遇到的

[qhd2004]

tidb版本为v5.2.2