TiFlash查询分析很慢

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

【TiDB 版本】
V4.0.11

【问题描述】
一个表3257w数据,普通count很快,加上一些条件后非常慢,20s+才出结果,即使加limit10,也需要20s+,查询条件没有用索引,因为走索引会直接走tikv,统计分析会更慢,我们统计分析都走tiflash,如下是SQL:
SELECT COUNT(1) FROM fact_2832 WHERE 1 = 1 AND
DATE(pub_time) >= 20210316 AND DATE(pub_time) <=20210407 AND bi_attr_id IN (4,5,6,7)


如下是执行计划:

表的schema如下:
CREATE TABLE fact_2832 (
id varchar(40) NOT NULL,
doc_id varchar(40) DEFAULT NULL,
account_id varchar(40) DEFAULT NULL,
pub_code varchar(40) DEFAULT NULL,
pub_type varchar(2) DEFAULT NULL,
pub_time datetime DEFAULT NULL,
subject1_id varchar(50) DEFAULT NULL,
subject2_id varchar(50) DEFAULT NULL,
subject3_id varchar(50) DEFAULT NULL,
subject4_id varchar(50) DEFAULT NULL,
subject5_id varchar(50) DEFAULT NULL,
subject6_id varchar(50) DEFAULT NULL,
subject_keyword text DEFAULT NULL,
aspect1_id varchar(50) DEFAULT NULL,
aspect2_id varchar(50) DEFAULT NULL,
aspect3_id varchar(50) DEFAULT NULL,
aspect4_id varchar(50) DEFAULT NULL,
aspect5_id varchar(50) DEFAULT NULL,
aspect6_id varchar(50) DEFAULT NULL,
aspect_keyword text DEFAULT NULL,
subject_sentiment_type_id int(11) DEFAULT NULL,
subject_sentiment_keyword text DEFAULT NULL,
sentiment_type_id int(11) DEFAULT NULL,
unit_content text DEFAULT NULL,
bi_status_id varchar(20) DEFAULT NULL,
bi_attr_id int(11) DEFAULT NULL,
process_start_time datetime DEFAULT NULL,
process_end_time datetime DEFAULT NULL,
reply_cnt int(11) DEFAULT NULL,
view_cnt int(11) DEFAULT NULL,
like_cnt int(11) DEFAULT NULL,
forward_cnt int(11) DEFAULT NULL,
dislike_cnt int(11) DEFAULT NULL,
collect_cnt int(11) DEFAULT NULL,
play_cnt int(11) DEFAULT NULL,
haha_cnt int(11) DEFAULT NULL,
love_cnt int(11) DEFAULT NULL,
wow_cnt int(11) DEFAULT NULL,
angry_cnt int(11) DEFAULT NULL,
sad_cnt int(11) DEFAULT NULL,
care_cnt int(11) DEFAULT NULL,
coin_cnt int(11) DEFAULT NULL,
danmaku_cnt int(11) DEFAULT NULL,
pv int(11) DEFAULT NULL,
keyword varchar(50) DEFAULT NULL,
keyword_frequency varchar(50) DEFAULT NULL,
media_id int(11) DEFAULT NULL,
media_type_id int(11) DEFAULT NULL,
dedup_label varchar(5) DEFAULT NULL,
doc_type varchar(5) DEFAULT NULL,
author_tag varchar(5) DEFAULT NULL,
flag_qc tinyint(1) DEFAULT NULL,
flag_reject tinyint(1) DEFAULT NULL,
PRIMARY KEY (id),
KEY doc_id (doc_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

强制走tikv和tiflash都是20s-35s


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

看执行计划部分,查询耗时主要在 root 即数据都被捞到上层执行运算,也就是 cast 的 date 字段并没有下推到 tiflash 执行。这是因为在 4.0.11 部分,cast 操作无法下推,参考文档

https://docs.pingcap.com/zh/tidb/v4.0/use-tiflash


确实是这么回事,我吧cast去掉后,执行时间从22s下降到8s了,现在是我加不加pubtime的筛选条件都是8s左右,感觉还是有些慢

这个还有优化的可能吗

试了下,如果再去掉distinct去掉,只是count doc_Id 很快,0.4s,加上distinct是8秒多,如果吧distinct换成groupby 来代替,则是14s,所以现在就是优化distinct了


你好,distinct 目前不支持下推,所以会慢一些。

如果可以接受近似结果,可以考虑使用 APPROX_COUNT_DISTINCT 代替 count(distinct )

2赞

我试了下加了这三个参数,快了1s,就是说distinct再4.0.11还无法下推tiflash是吧,5版本的MPP架构会有明显作用吗
SET @@tidb_opt_distinct_agg_push_down = 1;
SET @@tidb_allow_batch_cop = 1;
SET @@tidb_distsql_scan_concurrency = 80;

嗯嗯,试了下,近似结果很快,我反馈给业务部门看下能否接受,想问下,v5版本对tiflash的下推和distinct有提升吗

5.0版本 distinct 支持下推了吗

可以看下这里介绍

https://docs.pingcap.com/zh/tidb/v4.0/tune-tiflash-performance#tidb-相关参数调优

@Hacker_IslRgOns @HHHHHHULK
5.0.x 对 count distinct 也有一定优化,欢迎测试。

1赞