TiFlash查询分析很慢

[Lawrence (None)]

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

【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

---

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

[不懂就问 (zhouyueyue)]

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

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

[Lawrence (None)]

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

[Lawrence (None)]

这个还有优化的可能吗

[Lawrence (None)]

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

[JinheLin]

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

[flow-PingCAP]

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

[Lawrence (None)]

我试了下加了这三个参数，快了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;

[Lawrence (None)]

@flow-PingCAP

APPROX_COUNT_DISTINCT

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

[HHHHHHULK (好好学习，天天向上)]

5.0版本 distinct 支持下推了吗

[不懂就问 (zhouyueyue)]

可以看下这里介绍

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

[flow-PingCAP]

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