聚合查询很慢

#1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】 3.0.8

【问题描述】
耗时2.7m的聚合查询，其中sku_id为主键

image
image.png640×784 36.5 KB

执行计划如下

image
image.png1249×155 12.1 KB

数据共560W。请问如何优化加快查询速度
生产环境无法执行所提供的py脚本

#2

这种单表 统计查询 ，建议使用 TiDB 4.0 的 Tiflash 效果会非常好

这里看基本耗时在 tikv 回传 tidb ，和 tidb 进行 agg 操作。这两部分都会非常耗时。尤其 tidb 单点 agg 操作，耗时且容易出现 TiDB OOM 情况

#3

我们的数据都位于单点tidb上么？咋看出来的呢？tidb不是默认会进行分区分块的么？就是agg没有下推到tikv么？可以通过下推来解决么

#4

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-解读执行计划

#5

非常感谢，这里显示的cop是不是说明已经下推到cop了，那就不是tidb进行agg操作，而是在tikv上进行了agg操作吧。而且是进行的indexscan，而非fullscan，所以基本也没啥优化空间了。

image
image.png1249×155 12.1 KB

#6

把这个参数调大会不会有变化？tidb_index_serial_scan_concurrency

#7
  1. 上面回答的意思是，这种sql，如果可以配合tiflash，那么效果会更好。
  2. 如果没有tiflash，目前可以试试调整参数值，试试在session级别都调整到8，逐渐调大，看看效果如何。
    https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_hashagg_final_concurrency
    image
    image.png1032×465 33.7 KB
  3. 另外，如果参数值过大，占用的资源会更多，考虑下整体情况。
  4. 还有 tidb_index_serial_scan_concurrency 楼上提到的这个参数也可以试试。