为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】 3.0.8
【问题描述】
耗时2.7m的聚合查询，其中sku_id为主键
执行计划如下
数据共560W。请问如何优化加快查询速度
生产环境无法执行所提供的py脚本
这种单表 统计查询 ，建议使用 TiDB 4.0 的 Tiflash 效果会非常好
这里看基本耗时在 tikv 回传 tidb ，和 tidb 进行 agg 操作。这两部分都会非常耗时。尤其 tidb 单点 agg 操作，耗时且容易出现 TiDB OOM 情况
我们的数据都位于单点tidb上么？咋看出来的呢？tidb不是默认会进行分区分块的么？就是agg没有下推到tikv么？可以通过下推来解决么
1.数据存储是分布在 tikv 上的
2.部分计算可以下推到 tikv 帮助计算，但不是全部。https://docs.pingcap.com/zh/tidb/stable/expressions-pushed-down#下推到-tikv-的表达式列表
3.通过执行计划里面的 task 的类型判断算子是在哪里执行的 如果是 root 那就是 tidb 上计算
如果是 cop 那就是 tikv。ps 4.0 这里的显示会更明确
参考阅读：
https://docs.pingcap.com/zh/tidb/stable/explain-walkthrough#使用-explain-解读执行计划
非常感谢，这里显示的cop是不是说明已经下推到cop了，那就不是tidb进行agg操作，而是在tikv上进行了agg操作吧。而且是进行的indexscan，而非fullscan，所以基本也没啥优化空间了。
把这个参数调大会不会有变化？tidb_index_serial_scan_concurrency
- 上面回答的意思是，这种sql，如果可以配合tiflash，那么效果会更好。
- 如果没有tiflash，目前可以试试调整参数值，试试在session级别都调整到8，逐渐调大，看看效果如何。
https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_hashagg_final_concurrency
- 另外，如果参数值过大，占用的资源会更多，考虑下整体情况。
- 还有 tidb_index_serial_scan_concurrency 楼上提到的这个参数也可以试试。
感谢，这几个参数都试过了，作用不大，看来只有升级4.0了
好的，也可以试试 5.0 