大飞飞呀
2024 年7 月 24 日 12:37
1
【 TiDB 使用环境】生产环
SELECT /*+ max_execution_time(600000) ,READ_FROM_STORAGE(TIFLASH[`a`])*/ `a`.`CH_DEAL_ID`,DATE_FORMAT(`D_FINISHED_TIME`, '%Y-%m') AS `month_date`,`CH_ID_CARD_UC_ENCRYPT`,SUM(`I_AMOUNT`) OVER (PARTITION BY `CH_DEAL_ID`, DATE_FORMAT(`D_FINISHED_TIME`, '%Y-%m'), `CH_ID_CARD_UC_ENCRYPT`) FROM `stat`.`dwd_detail_si` AS `a` WHERE `I_STATUS` = 1 AND `I_USER_PAID_AGE` != -1 AND `D_FINISHED_TIME` >= '2024-01-01' LIMIT 100
执行计划
【遇到的问题：问题现象及影响】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
可能是由于 TiDB 在处理查询过程中需要维护一些中间状态或结果集，而 TiFlash 的内存没有变化是因为 TiFlash 不直接参与这部分数据处理。
第三行算子在 tidb 跑，没下推 tiflash， 你可以简单把 sum 改 FIRST_VALUE 试试算子有没有下推 tiflashhttps://docs.pingcap.com/zh/tidb/stable/window-functions
第1至第5行得执行计划root表示该层算子会在tidb server层执行，完成相关的数据读取和计算操作，从预估的行数可以看到有接近2千9百万行的数据拉到TiDB server 的内存里，这肯定会引起内存使用增加。
建议优化一下SQL，不然使用太多内存容易导致oom 发生。
Kongdom
2024 年7 月 25 日 00:37
5
你有几个tiflash节点？应该是用了tiflash的mpp导致你的limit无法下推到所有的tiflash节点，你执行set @@session.tidb_allow_mpp=0;之后再看下这个sql的执行计划，看看limit是否能够下推到某一个tiflash节点
h5n1
2024 年7 月 25 日 01:13
7
Window ：当前支持下推的窗口函数包括 ROW_NUMBER()、RANK()、DENSE_RANK()、LEAD()、LAG()、FIRST_VALUE() 和 LAST_VALUE()
不支持sum 窗口函数下推tiflash。所以需要再tidb读取大量数据计算
h5n1
2024 年7 月 25 日 02:33
10
支持sum作为单独聚合函数下推，至于窗口函数的得看官方吧。 你这SQL是不是可以直接sum .group by
大飞飞呀
2024 年7 月 25 日 02:35
11
直接sum .group by，那样不知道为啥，tiflash内存直接打满，150G，感觉有点扯
h5n1
2024 年7 月 25 日 03:33
16
可以升级到7.1.5版本试试sum…group by，有个tiflash 内存泄露的修复
h5n1
2024 年7 月 25 日 06:02
18
只有底层读取数据是在tiflash执行的，读取之后的聚合是在tidb层执行的，也就是各个节点返回的数据越多，tidb层资源消耗越大。