表顺序影响执行计划

禁用join reorder规则


看起来是 hint 不对,hint 试一下用 库名.别名 的方式。 /*+ INL_HASH_JOIN(d_users.a,d_users.c) */ 看看还有没有 warning 以及 hint 是否生效。

又多个了全表扫描,warnning也多了一个

辛苦再用 join on 的方式改写一下 SQL 。看看效果。

使用join on和不使用效果一样

  1. 更改表顺序后
  2. 更改表顺序前


https://docs.pingcap.com/zh/tidb/stable/statistics#导出统计信息
可以参考这个拿一下统计信息吗,我们再深入的看一下

哦 我看到了 不好意思问重复了

各位大佬有分析进展吗?

两个计划上都是 ac 先 join 然后再同 b join, 也就是 join 顺序是 ok 的

greedy reorder 算法的评估是 join 结果集结果的最优维护. 虽然 a 表上一个统计行数一个是 230141018.53 和一个是 4.14, 但是最终 ac join 结果集合的统计行数是 4.23 是一致的.

就单个表访问的方式差异而言 , 取决于其可选物理计划. 感觉是因为交换顺序之后, 导致 primary key 的回表路径被 prune 了, 选择了更差的 tablescan, 有统计信息的话可能会比较好复现一点

一般来说,多个表的连表查询,还是自己手动指定连接顺序比较好。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。