ClickHouse MergeTree 使用 ORDER BY 进行慢速选择

Posted 2023-03-25

【中文标题】ClickHouse MergeTree 使用 ORDER BY 进行慢速选择

【英文标题】：ClickHouse MergeTree slow SELECT with ORDER BY

【发布时间】：2019-12-16 15:47:21

【问题描述】：

我开始学习 CH 并且在尝试提高查询速度时似乎遇到了死胡同，表是这样创建的

CREATE TABLE default.stats(
  aa String, 
  ab String, 
  user_id UInt16, 
  ac UInt32,  
  ad UInt8, 
  ae UInt8, 
  created_time DateTime, 
  created_date Date, 
  af UInt8, 
  ag UInt32, 
  ah UInt32, 
  ai String, 
  aj String) 
ENGINE = MergeTree 
PARTITION BY toYYYYMM(created_time) 
ORDER BY(created_time, user_id)

我正在运行这样的查询

SELECT ad, created_time, ab, aa, user_id, ac, ag, af 
FROM stats 
WHERE user_id = 1 AND lowerUTF8(ab) = 'xxxxxxxxx' AND ad != 12 
ORDER BY created_time DESC 
LIMIT 50 OFFSET 0

这是 50 行集合中的结果。经过：2.881 秒。处理了 7462 万行

如果我在没有订单部分的情况下运行相同的查询，集合中有 50 行。经过：0.020 秒。处理了 49150 行

如果理论上查询只需要订购大约 10k（所有返回的行没有限制）行，为什么它似乎处理了表中的所有行？我错过了什么和/或如何提高 CH 的速度？

【参考方案1】：

尝试 ORDER BY created_time DESC, user_id

optimize_read_in_order 功能已在 ClickHouse 版本 19.14.3.3，2019-09-10 中实现

【讨论】：

大致相同的结果，没有顺序 50 行集合。经过：0.021 秒。处理了 16.38 万行，订单集 50 行。经过：1.855 秒。处理了 2431 万行，我还将我的 CH 版本更新为 19.17.5 修订 54428

没有where WHERE 1的查询的统计信息如何

你在这之后吗？ 74818400 行在集合中。经过：14.823 秒。处理了 7482 万行，4.31 GB（505 万行/秒，290.91 MB/秒。）

【参考方案2】：

CH 19.17.4.11
CREATE TABLE stats
(
    `aa` String,
    `ab` String,
    `user_id` UInt16,
    `ac` UInt32,
    `ad` UInt8,
    `ae` UInt8,
    `created_time` DateTime,
    `created_date` Date,
    `af` UInt8,
    `ag` UInt32,
    `ah` UInt32,
    `ai` String,
    `aj` String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(created_time)
ORDER BY (created_time, user_id)

insert into stats(created_time, user_id) select toDateTime(intDiv(number,100)), number%103 from numbers(100000000)


SELECT ad, created_time, ab, aa, user_id, ac, ag, af
FROM stats
ORDER BY created_time DESC
LIMIT 5 OFFSET 0

5 rows in set. Elapsed: 0.013 sec. Processed 835.84 thousand rows,


set  optimize_read_in_order = 0

SELECT ad, created_time, ab, aa, user_id, ac, ag, af
FROM stats
ORDER BY created_time DESC
LIMIT 5 OFFSET 0

5 rows in set. Elapsed: 0.263 sec. Processed 100.00 million rows

检查差异 设置 optimize_read_in_order = 0 VS 设置 optimize_read_in_order = 1

我不明白为什么 optimize_read_in_order 在你的情况下不起作用。