ClickHouse聚合前过滤优化：聚合查询行数处理问题求助

你遇到的核心问题是where type = 'registration'没有提前过滤数据，导致全表扫描。这通常是因为目标字段没有合适的索引或分区策略，ClickHouse无法快速定位符合条件的行。试试以下几种解决方案：

1. 给type字段添加二级索引 #

如果type字段的基数不高（取值种类少），直接给它加普通索引：

-- 添加索引
ALTER TABLE events ADD INDEX type_idx type TYPE minmax GRANULARITY 8192;
-- 物化索引（让索引生效）
ALTER TABLE events MATERIALIZE INDEX type_idx;

添加索引后，ClickHouse会先通过索引定位包含目标值的数据颗粒（granule），只读取这些颗粒里的行，不会扫全表。

2. 按type字段分区 #

如果type的取值固定且数量不多（比如只有几种事件类型），直接把它设为分区键：

ALTER TABLE events PARTITION BY type;

分区后，查询where type = 'registration'时，ClickHouse会直接跳过其他分区，只扫描registration对应的分区，处理行数就是该分区的1亿行左右。

3. 用物化视图预聚合 #

如果这类按type统计行数的查询很频繁，直接建一个预聚合的物化视图：

CREATE MATERIALIZED VIEW events_type_count
ENGINE = SummingMergeTree()
PRIMARY KEY (type)
AS SELECT type, count(*) AS cnt FROM events GROUP BY type;

之后查询直接从物化视图取结果：

SELECT cnt FROM events_type_count WHERE type = 'registration';

这种方式完全不用扫描原表，效率最高，适合高频查询场景。

验证优化效果 #

执行查询前可以用EXPLAIN ANALYZE查看实际处理的行数，或者在查询时查看system.processes表的rows_read字段，确认是否只处理了目标数据。

内容的提问来源于stack exchange，提问作者Artem Garnyshev