单表两千万数据,MySQL 4C8G,24ms ,clickhouse 2C4G,282ms
MySQL:
SELECT
corp_id,
corp_user_id,
SUM(totalxx_num) totalxx_num,
SUM(total_xxx_num) total_xxx_num
from xxx.xxxx
where corp_id = 'sdd' and dept_id = 100 and send_day >= '2023-03-01 00:00:00'and send_day <= '2023-04-25 00:00:00'
group by corp_id,corp_user_id;
CK:
SELECT
corp_id,
corp_user_id,
SUM(totalxx_num) totalxx_num,
SUM(total_xxx_num) total_xxx_num
from xxx.xxxx
where corp_id = 'sdd' and dept_id = 100 and send_day >= toDate('2023-03-01 00:00:00') and send_day <= toDate('2023-04-25 00:00:00')
group by corp_id,corp_user_id;
DDL:
create table xxxx
(
id Int64,
corp_id String,
user_id Int64,
corp_user_id String,
totalxx_num Int32,
total_xxx_num Int32,
send_day Date
)
engine = MergeTree PARTITION BY toMonday(send_day)
PRIMARY KEY id
ORDER BY (id, corp_id, user_id, send_day)
SETTINGS index_granularity = 8192;
1
standchan 2023-04-26 11:18:31 +08:00 1
CK ddl 的分区感觉有点奇怪,分区对 ck 的性能影响很大。你使用 toMonday 分区,2 千万的数据量那分区就贼多了吧,你查一下你这批数据分了多少区呢,在 sys 表里面有,看一下呢
|
4
x308989414q 2023-04-26 12:47:05 +08:00 via iPhone 1
查询尽量不要跨分区
|
5
troywinter 2023-04-26 18:08:38 +08:00 1
2000 万数据感觉 ck 都没必要分区,或者根据查询场景用 corp_id 分区。
|
6
RangerWolf 2023-04-26 23:33:10 +08:00
我感觉问题在 order by 上。
order by 的顺序是 ORDER BY (id, corp_id, user_id, send_day) 而你的查询值没有用到 id ,导致要扫描的行数还是太多了。你试试看在 order by 之中把 id 去掉或者放到后面,查询速度应该有明显提升。 只能说盲猜,猜错勿怪 |
7
OliverDD 2023-04-27 10:39:42 +08:00 via iPhone
看看你的 primary key…id…但是查询没用到。order by 第一个竟然是 id ,这种高基数键不应该放首位;其次,不知道这几个 id 是不是随机值还是自增的,随机的值不应该放在 order by 里面
|
8
OliverDD 2023-04-27 10:40:53 +08:00 via iPhone
你可以用 explain indexes=1 你的 sql;来看看你的 sql 命中索引情况,我理解,应该是全盘扫描
|