ClickHouse 26.4 版本发布说明：SQL兼容性提升，COUNT DISTINCT更快了！

关注

原创最新推荐文章于 2026-11-08 16:01:54 发布 431 阅读 AI 写同款· GEO 优化 ›

多维聚合实战：从Pandas透视表到OLAP引擎的系统化数据操作多维聚合是现代数据分析的核心能力，本质是将扁平数据升维为可切片、钻取、上卷的立体立方体，支撑动态业务洞察。其底层依赖维度建模（如星型模式）与可加性度量设计，技术实现涵盖Pandas pivot_table、Doris、ClickHouse等多层架构选型。关键价值在于统一数据口径、加速自助分析、赋能实时BI看板，广泛应用于电商销售分析、客户分群、区域业绩归因等场景。本文聚焦Multi-Dimensional Aggregation与Data Manipulation在工程落地中的设计权衡、性能陷阱与口径治理实阅读详情

本文字数：10732；估计阅读时间：27分钟

作者：ClickHouse Team

又是新一月，这意味着又到了发布新版本的时候了！

ClickHouse 26.4 版本包含 39 项新功能 🌷、45 项性能优化 🐇 和 238 个 bug 修复 🐝。

本次发布带来了更多与 SQL 兼容的功能、更快的 COUNT DISTINCT、更美观的 EXPLAIN 等改进！

新贡献者

热烈欢迎所有参与 26.4 版本贡献的新成员！ClickHouse 社区的蓬勃发展令人备受鼓舞，我们由衷感谢所有贡献者，正是他们的付出让 ClickHouse 广受欢迎。

以下是新贡献者的姓名：

Alexander Kuleshov, Alsu, Anton Frost, Aruj Bansal, Asya, ClickGap AI Bot, Denys Melnyk, Diego Gomes Tome, Dustin Healy, Evgeny Kuzin, Farid Adam, Francisco Garcia Florez, Gagan Dhakrey, Gleb Popov, Groene AI, Ivan Mantova, Jaap Elst, Jack Knudson, James Cunningham, JingYanchao, K, Kc Balusu, Matheus Nerone, Michael Russell, MukundaKatta, Nikita Semenov, Pavel Kravtsov, Peng, RenzoMXD, Sergey Veletskiy, Takumi Hara, Timothy Kurniawan, Wenyu Chen, XiaoBinMu, Yuri Fedoseev, ashrithb, asyablue22, dwagner-decix, egor romanov, groeneai, liuguangliang, manerone, nerve-bot, simonhammes, sourcelliu, xiaobin

小提示：如果您好奇我们如何生成此列表，详情请点击此处（https://gist.github.com/gingerwizard/5a9a87a39ba93b422d8640d811e269e9）。

查看媒体链接：https://youtu.be/9lSVy7k2EoI

您也可以查看演示文稿的幻灯片（https://presentations.clickhouse.com/2026-release-26.4/）。

SQL 兼容性：VALUES 作为表表达式、EXTRACT 和 SET TIME ZONE

26.4 版本引入了更多与标准 SQL 语法兼容的功能。我们将仅介绍其中几个，您可以查阅演示文稿幻灯片以了解更多详情（https://presentations.clickhouse.com/2026-release-26.4/?full#16）。

查看媒体链接：https://youtu.be/VE2DHww-Z_k

VALUES 作为表表达式

贡献者：Desel72

首先我们来看 VALUES。在此版本之前，其调用方式如下：

SELECT * 
FROM VALUES((1, 'a'), (2, 'b'), (3, 'c'));

   ┌─c1─┬─c2─┐
1. │  1 │ a  │
2. │  2 │ b  │
3. │  3 │ c  │
   └────┴────┘

而现在，我们也可以将其作为表表达式调用，示例如下：

SELECT * 
FROM (VALUES (1, 'a'), (2, 'b'), (3, 'c'));

   ┌─c1─┬─c2─┐
1. │  1 │ a  │
2. │  2 │ b  │
3. │  3 │ c  │
   └────┴────┘

我们现在还可以为列设置别名，这在使用 VALUES 进行 join 查询时非常有用。例如，我们可以避免使用以下写法：

SELECT
    c.c2,
    o.c2
FROM VALUES((1, 'Alice'), (2, 'Bob')) AS c
INNER JOIN VALUES((1, 250), (2, 100), (1, 75)) AS o 
ON c.c1 = o.c1;

   ┌─c2────┬─o.c2─┐
1. │ Alice │  250 │
2. │ Alice │   75 │
3. │ Bob   │  100 │
   └───────┴──────┘

通过为列命名，我们可以让查询更易于理解：

SELECT c.name, o.amount
  FROM (VALUES (1, 'Alice'), (2, 'Bob')) AS c(id, name)
  JOIN (VALUES (1, 250), (2, 100), (1, 75)) AS o(customer_id, amount)
  ON c.id = o.customer_id;

   ┌─name──┬─amount─┐
1. │ Alice │    250 │
2. │ Alice │     75 │
3. │ Bob   │    100 │
   └───────┴────────┘

EXTRACT

贡献者：Alexey Milovidov

EXTRACT 运算符（在处理日期时使用）现在支持 PostgreSQL 风格的单位，如下面查询所示：

SELECT
  EXTRACT(EPOCH      FROM now())   AS epoch,
  EXTRACT(DOW        FROM today()) AS dayOfWeek,
  EXTRACT(DOY        FROM today()) AS dayOfYear,
  EXTRACT(ISODOW     FROM today()) AS isoDOW,
  EXTRACT(ISOYEAR    FROM today()) AS isoYear,
  EXTRACT(WEEK       FROM today()) AS isoWeek,
  EXTRACT(CENTURY    FROM today()) AS century,
  EXTRACT(DECADE     FROM today()) AS decade,
  EXTRACT(MILLENNIUM FROM today()) AS millennium;

Row 1:
──────
epoch:      1777992683
dayOfWeek:  2
dayOfYear:  125
isoDOW:     2
isoYear:    2026
isoWeek:    19
century:    21
decade:     202
millennium: 3

设置时区

由 phulv94 贡献

还有一个新的 SQL 标准别名用于设置时区。首先，让我们检查我当前的区域：

SELECT timezone(), formatDateTime(now(), '%Y-%m-%d %H:%M:%S %z');

SELECT timezone(), formatDateTime(now(), '%Y-%m-%d %H:%M:%S %z');

   ┌─timezone()────┬─formatDateTim⋯H:%M:%S %z')─┐
1. │ Europe/London │ 2026-05-05 15:May:47 +0100 │
   └───────────────┴────────────────────────────┘

现在，我们将其设置为 Amsterdam：

SET TIME ZONE 'Europe/Amsterdam';

SET TIME ZONE 'Europe/Amsterdam';

如果我们重新运行上面的查询：

   ┌─timezone()───────┬─formatDateTim⋯H:%M:%S %z')─┐
1. │ Europe/Amsterdam │ 2026-05-05 16:May:59 +0200 │
   └──────────────────┴────────────────────────────┘

其他兼容性改进

不仅如此，现在还支持 NATURAL JOIN，OVERLAY 可直接兼容，复合 INTERVAL 字面量也受支持，等等！

LIKE 使用文本索引

由 Elmi Ahmadov 贡献

从 ClickHouse 25.4 开始，当 LIKE / ILIKE 查询模式为 不含空格的字母数字字符 且文本索引分词器为 splitByNonAlpha 时，ClickHouse 会使用倒排索引来加速这些查询。它通过扫描倒排索引字典而非执行全表扫描来查找匹配模式。

让我们看看这在我们的信赖的 HackerNews 数据集上如何工作，首先使用 clickhousectl 让 ClickHouse 26.4 在我的笔记本电脑上运行起来：

chctl local install 26.4

然后我们启动它：

chctl local server start --version 26.4

并使用 ClickHouse 客户端连接：

chctl local client --name default -mn

接下来，我们将创建我们的 HackerNews 表：

CREATE TABLE hackernews
(
    `id` Int64,
    `deleted` Int64,
    `type` String,
    `by` String,
    `time` DateTime64(9),
    `text` String,
    `dead` Int64,
    `parent` Int64,
    `poll` Int64,
    `kids` Array(Int64),
    `url` String,
    `score` Int64,
    `title` String,
    `parts` Array(Int64),
    `descendants` Int64
    GRANULARITY 128
)
ORDER BY time;

然后我们将插入数据：

INSERT INTO hackernews 
SELECT *
FROM url('https://datasets-documentation.s3.eu-west-3.amazonaws.com/hackernews/hacknernews.csv.gz', 'CSVWithNames')

接下来，我们将在 text 列上使用 splitByNonAlpha 分词器添加一个文本索引：

ALTER TABLE hackernews
ADD INDEX text_tokens_idx text 
TYPE text(tokenizer='splitByNonAlpha') 
GRANULARITY 1;

并物化该索引：

ALTER TABLE hackernews
(MATERIALIZE INDEX text_tokens_idx)
SETTINGS mutations_sync = 1;

此优化已在 26.4 中启用，但可以使用 use_text_index_like_evaluation_by_dictionary_scan 设置进行控制。以下查询统计了有多少 Hacker News 帖子提到了 Kubernetes：

SELECT count()
FROM hackernews
WHERE text LIKE '%Kubernetes%'
SETTINGS use_text_index_like_evaluation_by_dictionary_scan=0;

   ┌─count()─┐
1. │   20070 │
   └─────────┘

1 row in set. Elapsed: 0.832 sec. Processed 18.25 million rows, 6.29 GB (21.93 million rows/s., 7.56 GB/s.)
Peak memory usage: 88.18 MiB.

1 row in set. Elapsed: 0.624 sec. Processed 18.25 million rows, 6.29 GB (29.23 million rows/s., 10.08 GB/s.)
Peak memory usage: 87.93 MiB.

1 row in set. Elapsed: 0.638 sec. Processed 18.25 million rows, 6.29 GB (28.60 million rows/s., 9.86 GB/s.)
Peak memory usage: 86.01 MiB.

现在使用优化后：

SELECT count()
FROM hackernews
WHERE text LIKE '%Kubernetes%'
SETTINGS use_text_index_like_evaluation_by_dictionary_scan=1;

   ┌─count()─┐
1. │   20070 │
   └─────────┘

1 row in set. Elapsed: 0.208 sec. Processed 18.25 million rows, 18.25 MB (87.53 million rows/s., 87.53 MB/s.)
Peak memory usage: 2.07 MiB.

1 row in set. Elapsed: 0.225 sec. Processed 18.25 million rows, 18.25 MB (80.98 million rows/s., 80.98 MB/s.)
Peak memory usage: 2.07 MiB.

1 row in set. Elapsed: 0.234 sec. Processed 18.25 million rows, 18.25 MB (77.83 million rows/s., 77.83 MB/s.)
Peak memory usage: 2.07 MiB.

处理的行数相同，但使用此优化的查询的最佳运行时间为 208 毫秒，相比 624 毫秒，速度提升了三倍多。

如果我们比较查询计划，可以看到使用优化的查询扫描的颗粒数减少了 1000 多个。

未使⽤倒排索引：

┌─explain─────────────────────────────────────────────────────────┐
 1. │ Output: count()                                                 │
 2. │                                                                 │
 3. │ Aggregating                                                     │
 4. │ └──Filter ((WHERE + Change column names to column identifiers)) │
 5. │    └──ReadFromMergeTree (default.hackernews)                    │
 6. │          Indexes:                                               │
 7. │            PrimaryKey                                           │
 8. │              Condition: true                                    │
 9. │              Parts: 6/6                                         │
10. │              Granules: 3533/3533                                │
11. │            Skip                                                 │
12. │              Name: text_tokens_idx                              │
13. │              Description: text GRANULARITY 100000000            │
14. │              Condition: (mode: All; tokens: [])                 │
15. │              Parts: 6/6                                         │
16. │              Granules: 3533/3533                                │
17. │            Ranges: 6                                            │
    └─────────────────────────────────────────────────────────────────┘

使⽤倒排索引：

    ┌─explain──────────────────────────────────────────────┐
 1. │ Output: count()                                      │
 2. │                                                      │
 3. │ Aggregating                                          │
 4. │ └──Filter                                            │
 5. │    └──ReadFromMergeTree (default.hackernews)         │
 6. │          Indexes:                                    │
 7. │            PrimaryKey                                │
 8. │              Condition: true                         │
 9. │              Parts: 6/6                              │
10. │              Granules: 3533/3533                     │
11. │            Skip                                      │
12. │              Name: text_tokens_idx                   │
13. │              Description: text GRANULARITY 100000000 │
14. │              Condition: (mode: All; tokens: [])      │
15. │              Parts: 6/6                              │
16. │              Granules: 2247/3533                     │
17. │            Ranges: 190                               │
    └──────────────────────────────────────────────────────┘

更快的 COUNT DISTINCT

Jiebin Sun 贡献

在高核数机器上，uniqExact (由 COUNT(DISTINCT ...) 使用) 有以下几项改进：

• ClickHouse 在合并阶段不再创建冗余线程。 uniqExact 使用带有 256 个桶的两级哈希表，但在此之前，ClickHouse 无论如何都会创建多达 max_threads 个线程，其中许多线程会处于空闲状态并立即退出。

• 合并 N 个中间哈希表（每个聚合线程对应一个）时，线程池会初始化 N 次，这导致总共 O(N × threads) 次线程创建和严重的锁竞争。现在，所有 N 个哈希表都在单次遍历中完成合并——每个线程同时处理所有哈希表中的一个桶，从而将线程池初始化次数从 O(N) 减少到 O(1) 。

在我们的一些基准测试中，一台 288 核机器上的性能提升达到 3 到 15 倍。

然而，这主要是一项针对多核机器的优化——我在我的 Mac M2 Max (拥有 12 个核心) 上使用 HackerNews 数据集进行了尝试，但并未观察到任何改进！

更加美观的 EXPLAIN

Kirill Kopnev 贡献

EXPLAIN PLAN pretty=1 现在能以人类可读的形式打印表达式，显示顶层输出列和每步输出列，并为 JOIN 操作标注预估的行数和局部性。

让我们通过以下查询，来看看它是如何工作的：

EXPLAIN pretty = 1
SELECT by, count()
FROM hackernews
WHERE (text LIKE '%OpenAI%') AND (text LIKE '%Google%')
GROUP BY ALL
ORDER BY count() DESC, by
LIMIT 10;

26.3


   ┌─explain────────────────────────────────────────────────────────────────────────────┐
1. │ Expression (Project names)                                                         │
2. │ └──Limit (preliminary LIMIT)                                                       │
3. │    └──Sorting (Sorting for ORDER BY)                                               │
4. │       └──Expression ((Before ORDER BY + Projection))                               │
5. │          └──Aggregating                                                            │
6. │             └──Expression (Before GROUP BY)                                        │
7. │                └──Expression ((WHERE + Change column names to column identifiers)) │
8. │                   └──ReadFromMergeTree (default.hackernews)                        │
   └────────────────────────────────────────────────────────────────────────────────────┘

26.4

    ┌─explain─────────────────────────────────────────────────────┐
 1. │ Output: by, count()                                         │
 2. │                                                             │
 3. │ Expression (Project names)                                  │
 4. │ └──Limit (preliminary LIMIT)                                │
 5. │    └──Sorting (Sorting for ORDER BY)                        │
 6. │       └──Expression ((Before ORDER BY + Projection))        │
 7. │          └──Aggregating                                     │
 8. │             └──Expression (Before GROUP BY)                 │
 9. │                └──Expression                                │
10. │                   └──ReadFromMergeTree (default.hackernews) │
    └─────────────────────────────────────────────────────────────┘

JSONAllValues + 文本索引

Anton Popov 贡献

ClickHouse 26.4 Values 函数，它会将 JSON 列中的每个叶子值作为 Array(String) 类型返回。基于此，我们可以创建一个文本索引，从而实现对 JSON 子列更高效的过滤。

让我们借助 StatsBomb 数据集来看看它是如何工作的。通过运行以下命令，我们将在本地机器上获取一个数据子集：

git clone --filter=blob:none --sparse https://github.com/statsbomb/open-data.git
cd open-data
git sparse-checkout set data/events

我们将使用 clickhouse-local 创建以下表格：

CREATE TABLE events (
      match_id UInt32,
      json JSON(id String, index UInt32),
      INDEX vals JSONAllValues(json) TYPE text(tokenizer = 'ngrams') GRANULARITY 1
  )
  ENGINE = MergeTree
  ORDER BY (match_id, json.index);

然后插入数据：

INSERT INTO events
SELECT
  toUInt32(replaceRegexpOne(_file, '\\.json$', '')) AS match_id,
  json
FROM file('open-data/data/events/*.json', JSONAsObject);

12188949 rows in set. Elapsed: 1275.404 sec. Processed 12.19 million rows, 10.48 GB (9.56 thousand rows/s., 8.22 MB/s.)
Peak memory usage: 1.87 GiB.

为了更好地理解这个索引是如何工作的，我们来看一下 JSONAllValues 函数会返回什么：

SELECT JSONAllValues(json) FROM events LIMIT 1
FORMAT Vertical;

JSONAllValues(json): ['[36.4,21.7]','1.013174','000000b5-8156-429d-9088-e62a6ac2ea0d','2529','[36.8,20]','60','2','4','From Throw In','10958','Chris Smalling','5','Left Center Back','123','39','Manchester United','[\'5fbbde9b-74ab-48e9-9873-ef956db384de\',\'fd43cc18-c37b-438a-8a40-a8bb50e59469\']','18','39','Manchester United','00:15:18.727','43','Carry']

这个数据集只有 1200 多万条记录，还不太足以体现索引带来的影响，所以我们先把数据重复复制几轮：

ALTER TABLE events
ATTACH PARTITION ID 'all'
FROM events;

0 rows in set. Elapsed: 3.892 sec.
0 rows in set. Elapsed: 7.957 sec.
0 rows in set. Elapsed: 15.894 sec.
0 rows in set. Elapsed: 33.655 sec.
0 rows in set. Elapsed: 68.870 sec.

现在，记录数就多多了：

SELECT count()
FROM events;

   ┌───count()─┐
1. │ 390046368 │ -- 390.05 million
   └───────────┘

以下查询返回与 Lionel Messi 相关的行数：

SELECT count()
FROM events
WHERE json.player.name = 'Lionel Andrés Messi Cuccittini'
SETTINGS use_skip_indexes = 1;

我们可以通过设置 use_skip_indexes = 0 来禁用文本索引。运行此查询将得到以下结果：

   ┌─count()─┐
1. │ 4268960 │ -- 4.27 million
   └─────────┘

我们将在不使用索引的情况下运行该查询三次：

1 row in set. Elapsed: 1.505 sec. Processed 390.05 million rows, 13.87 GB (259.20 million rows/s., 9.22 GB/s.)
Peak memory usage: 48.23 MiB.

1 row in set. Elapsed: 1.666 sec. Processed 390.05 million rows, 13.87 GB (234.12 million rows/s., 8.32 GB/s.)
Peak memory usage: 48.23 MiB.

1 row in set. Elapsed: 1.668 sec. Processed 390.05 million rows, 13.87 GB (233.88 million rows/s., 8.32 GB/s.)
Peak memory usage: 48.23 MiB.

并在使用索引的情况下运行该查询三次：

1 row in set. Elapsed: 1.139 sec. Processed 80.64 million rows, 3.23 GB (70.80 million rows/s., 2.84 GB/s.)
Peak memory usage: 69.25 MiB.

1 row in set. Elapsed: 1.096 sec. Processed 80.64 million rows, 3.23 GB (73.61 million rows/s., 2.95 GB/s.)
Peak memory usage: 68.93 MiB.

1 row in set. Elapsed: 1.087 sec. Processed 80.64 million rows, 3.23 GB (74.21 million rows/s., 2.97 GB/s.)
Peak memory usage: 74.13 MiB.

从处理的行数来看，索引将需要扫描的数据量减少了近5倍。在不使用索引的情况下，最佳时间为1,505毫秒；而使用索引时，最佳时间为1,087毫秒，查询性能提升了约50%。