V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lbllol365
V2EX  ›  程序员

大佬们麻烦帮忙看下这个 CK 查询速度为啥比 MySQL 慢

  •  
  •   lbllol365 · 337 天前 · 1222 次点击
    这是一个创建于 337 天前的主题,其中的信息可能已经有所发展或是发生改变。

    单表两千万数据,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;
    
    8 条回复    2023-04-27 10:40:53 +08:00
    standchan
        1
    standchan  
       337 天前   ❤️ 1
    CK ddl 的分区感觉有点奇怪,分区对 ck 的性能影响很大。你使用 toMonday 分区,2 千万的数据量那分区就贼多了吧,你查一下你这批数据分了多少区呢,在 sys 表里面有,看一下呢
    lbllol365
        2
    lbllol365  
    OP
       337 天前
    @standchan system.parts 表里查有 34 个分区
    simonlu9
        3
    simonlu9  
       337 天前   ❤️ 1
    @lbllol365 打开调式模式,看看执行计划
    x308989414q
        4
    x308989414q  
       337 天前 via iPhone   ❤️ 1
    查询尽量不要跨分区
    troywinter
        5
    troywinter  
       336 天前   ❤️ 1
    2000 万数据感觉 ck 都没必要分区,或者根据查询场景用 corp_id 分区。
    RangerWolf
        6
    RangerWolf  
       336 天前
    我感觉问题在 order by 上。
    order by 的顺序是 ORDER BY (id, corp_id, user_id, send_day)
    而你的查询值没有用到 id ,导致要扫描的行数还是太多了。你试试看在 order by 之中把 id 去掉或者放到后面,查询速度应该有明显提升。

    只能说盲猜,猜错勿怪
    OliverDD
        7
    OliverDD  
       336 天前 via iPhone
    看看你的 primary key…id…但是查询没用到。order by 第一个竟然是 id ,这种高基数键不应该放首位;其次,不知道这几个 id 是不是随机值还是自增的,随机的值不应该放在 order by 里面
    OliverDD
        8
    OliverDD  
       336 天前 via iPhone
    你可以用 explain indexes=1 你的 sql;来看看你的 sql 命中索引情况,我理解,应该是全盘扫描
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5242 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 09:36 · PVG 17:36 · LAX 02:36 · JFK 05:36
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.