聚合查询很慢

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

【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

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