我看他前面的描述，我感觉是他开了mpp，这个执行计划也走了mpp，不过没开动态分区裁剪。
在静态分区裁剪的情况下，分区之间的聚合就到tidb上做了。
看你的执行计划，确实应该没有开动态裁剪，你可以查一下SHOW VARIABLES LIKE ‘%tidb_partition_prune_mode%’;
，如果是static，可以SET tidb_partition_prune_mode=‘dynamic’;先修改当前session成dynamic，重新explain anlzye跑一下这个sql，看下执行计划
从5.4升级上来的的话，确实默认还会是static，因为5.4的时候默认是static的
1 个赞
可以session级改成动态试试会不会快一些。
mpp模式下，最理想的执行计划就是task这一栏，上面是几行root，下面全是mpp[tiflash]。
这就意味着tiflash完成了绝大部分的计算，tidb直接拿结果。
set tidb_allow_mpp=on;
set tidb_enforce_mpp=on;
session级把这两个变量打开，如果还不走mpp，应该可以通过show warnings看到原因。
分区表和tiflash是真的很不搭啊，问题多多的，session开启强制mpp再试试
set tidb_enforce_mpp=on;
好滴，我再打开试下
show warnings
有内容嘛？
https://docs.pingcap.com/zh/tidb/stable/use-tiflash-mpp-mode#控制是否选择-mpp-模式
应该是有warning告诉你为什么不能走mpp的。
怎么看你这个sql都是一个非常典型的聚合计算，这就应该是列存的优势场景。
确实是一个聚合，里面有一个Sum的计算。这张表是一个整合其他多张业务表后的宽表。
warning说缺少全局统计信息，所以没有开启动态分区裁剪。
你可能需要对这个大表analyze一下。
analyze大表，消耗时间较长，我得找个业务低峰时段，进行操作。等执行完后，再次验证，再来回帖。谢谢大佬
1 个赞
analyze后，速度嗖嗖的！
升级到6.5.8，就可以了。手动收集需要注意下要在创建分区之后
之前，是从v5.4.0直接升级到v6.5.0版本，但是，那个动态裁剪参数，并没有跟着自动设置为默认值。升级6.5.8，也不一定会自动变。目前，这张表已经是分区表，在低峰执行analyze应该没有其他的坑。