应该是个bug,优化器选择问题，感觉和内存参数有关，优化器把它考虑进去了，反而得不到优化的解

[image] 一般是以第一次执行会有这种情况 [image]

[image] 有时候有用，有时候很慢，很玄学

这个参数我之前调过

[image] 5.3我也试了一下，也会出现很慢的情况

10G [image]

没看不来什么不同

[image] 看了一下我的执行计划，走了indexHashJoin [image] 占用89G tidb内存，不太清楚为什么会走indexHashJoin

磁盘是nvme，我的是4.0.15版本，看了执行计划，两个analyze执行计划不一样；tidb_v5.3_4.0.15_Q5.txt (52.9 KB) [image] 表结构应该没问题

[image] 健康度，没有问题，但是到了tidb侧实际执行的行数远大于预估

MySQL [tpch_10]> explain analyze SELECT n_name, sum(l_extendedprice * (1 - l_discount)) AS revenue FROM customer, orders, lineitem, supplier, nation, region WHERE c_custkey = o_custkey AND l_orderkey = o_orderkey AND l_suppkey = s_suppkey AND c_nationkey = s_nationkey AND s…

我试一下

chaos.log (5.1 MB) 日志见文件

k8s中tidb集群信息： [image]

好的。

tispark+tiflash使用到了mpp功能吗