TiFlash统计分析很慢

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

【概述】 场景 + 问题概述
一个最简单的groupby sql,2000w数据,组tiflash,特别慢

EXPLAIN ANALYZE SELECT doc_id,pub_code,MAX(pub_time) AS pub_time,
MAX(IFNULL(like_cnt,0) + IFNULL(collect_cnt,0)

  • IFNULL(forward_cnt, 0) + IFNULL(reply_cnt, 0)) engagements
    FROM bdp_stage.fact_1218
    WHERE pub_code = “bg_m_sinacn”
    GROUP BY doc_id, pub_code
    ORDER BY engagements DESC
    LIMIT 100;


执行计划见附件:
explain.txt (4.0 KB)

【 TiDB 版本】
v4.0.13

有时甚至会把tidb server弄挂,为什么sql语句中是一个groupby,为什么执行计划两个groupby,一个走tiflash,一个走了tidb?

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

  1. 在 tiflash 进行了一次聚合,之后需要在 tidb 再进行聚合后的聚合。 这个 sql 没法在tiflash 完成limit,所以都需要在 tidb 执行,导致慢。
  2. 尝试调大参数 tidb_hashagg_partial_concurrency 和 tidb_hashagg_final_concurrency 为 8 看看是否有改善,5.0 已经废弃不影响,先修改看看。
    https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_hashagg_partial_concurrency

好的,我可以试下,有个疑问,为啥不能提前在tiflash limit呢,limit100,是否可以再每个tiflash 算出来max后取前100,每个tiflash的前100同步到tidb再求最后的100?

另外我发现我们很多SQL都是类似这样的,很多部分都要走tidb侧,那是不是把tidb的cpu和内存加大些会计算的快点?

还有我们使用的4.0.13,很多join的操作,是否可以下推到tiflash?我看执行计划join都是走tidb

请问下,您有几个 tiflash 节点?

3个tiflash,36C/72G内存

可以试试升级到 v5.0.2 吗?

生产目前是4.0.13,最近不会进行大版本升级

这个版本,目前看只能试试调大参数了,多谢。

我设置了很多tiflash,tidb的相关参数,感觉也没起多大作用,也没下推到tiflash,把tidb调成36c/72g,也并没有加速计算是啥情况, 设置了join、count distinct下推tiflash,看执行计划并没有作用,还是在tidb执行的

目前这个版本没太多方法,可以找个测试环境,尝试升级使用 MPP 测试下吧。


那就是文档写的有问题吗

嗨,已经升级5.0.2进行测试,更慢了,我指定了a表走tiflash,但是没用,而且没看出来mpp的执行计划,而且我发现只要有索引必走索引,没有对索引字段做过滤也走索引?那不是多走一层吗?为啥我升级了5.0.2后强制走tiflash也不管用了?

4.0.13版本,强制走tiflash,20s就出来了,5.0.2强制走tiflash却不管用,还更慢了。。

收集统计信息后, 麻烦把升级后,sql 默认的执行计划 和 强制走 tiflash 的执行计划 文本信息上传下,多谢。

这个是默认执行计划:

这个是强制走tiflash执行计划:

这个是建表语句:
CREATE TABLE document_ndc_all (
customer_id varchar(50) DEFAULT NULL,
md5_doc_id varchar(50) NOT NULL,
doc_type_id int(11) DEFAULT NULL,
media_id int(11) DEFAULT NULL,
media_type_id int(11) DEFAULT NULL,
region_type_id int(11) DEFAULT NULL,
headline text DEFAULT NULL,
doc_url text DEFAULT NULL,
account_name text DEFAULT NULL,
pub_time datetime DEFAULT NULL,
pub_date_time datetime DEFAULT NULL,
pub_day_date datetime DEFAULT NULL,
pub_week_date datetime DEFAULT NULL,
pub_month_date datetime DEFAULT NULL,
pub_quarter_date datetime DEFAULT NULL,
pub_year_date datetime DEFAULT NULL,
pub_hour_date datetime DEFAULT NULL,
reply_cnt int(11) DEFAULT NULL COMMENT ‘评论数:文本,短视频’,
forward_cnt int(11) DEFAULT NULL COMMENT ‘转发数:文本’,
like_cnt int(11) DEFAULT NULL COMMENT ‘点赞数:文本,短视频’,
view_cnt int(11) DEFAULT NULL COMMENT ‘阅读数:WBI’,
gift_cnt int(11) DEFAULT NULL COMMENT ‘礼物数:直播’,
user_cnt int(11) DEFAULT NULL COMMENT ‘在线观看峰值:直播’,
duration int(11) DEFAULT NULL COMMENT ‘播放时长:直播、短视频’,
folder_ids_str text DEFAULT NULL,
sentiment_type_ids_str varchar(500) DEFAULT NULL,
event_time datetime DEFAULT CURRENT_TIMESTAMP,
action int(11) DEFAULT NULL COMMENT ‘0:delete, 1:insert, 2:update’,
account_id varchar(100) DEFAULT NULL,
link_type_id int(11) DEFAULT NULL,
link_status_id int(11) DEFAULT NULL,
sina_verified_type_id int(11) DEFAULT NULL,
section text DEFAULT NULL,
cluster_id varchar(100) DEFAULT NULL,
sina_verified_group_id int(11) DEFAULT NULL,
cts datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (md5_doc_id) /*T![clustered_index] NONCLUSTERED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

另一个表:
CREATE TABLE dim_fid_sentid (
md5_doc_id varchar(50) DEFAULT NULL,
folder_id int(11) DEFAULT NULL,
sentiment_type_id int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

文档:建表.txt (2.1 KB)

谢谢,方便上传下完整的执行计划吗? 放到txt文件上传下,辛苦了,多谢。

好的
执行计划.txt (16.5 KB)

这里只有一张表,建议把所有相关表的 create 语句上传。上传方式:
show create table xx;
把对应的 create 语句放到文档中;
然后上传文档,这样就避免中英文 ‘’ 问题。

好的,更新在上面了

另外,更新一下所有相关表的统计信息,
analyze table xxx;