ClickHouse过滤优化：PREWHERE与WHERE性能对比-代码聚汇网

ClickHouse过滤优化：PREWHERE与WHERE性能对比

nzy233

1. ClickHouse过滤机制深度解析：PREWHERE与WHERE的本质差异

作为一名长期使用ClickHouse处理海量数据的工程师，我发现很多团队在使用这个高性能列式数据库时，对过滤条件的理解仍停留在传统SQL层面。今天我想从存储引擎的底层视角，分享PREWHERE和WHERE这两个看似相似的关键字背后截然不同的执行哲学。

ClickHouse的列式存储架构决定了它处理数据的方式与传统行式数据库（如MySQL）有本质区别。当我们执行一个带有过滤条件的查询时，WHERE子句会强制读取查询涉及的所有列数据到内存，再进行过滤。这种"全量读取+后过滤"的模式在列数多、数据量大的场景下会造成严重的IO和内存浪费。而PREWHERE则是专为列式存储设计的"先过滤后读取"机制，它像一位精明的图书管理员，先通过索引找到需要的书（行），再只取出这些书的内容（列），而非搬空整个书架。

2. 执行原理与技术实现对比

2.1 WHERE的传统执行模型

在行式数据库中，WHERE的工作方式非常直观——它逐行扫描数据，对每行记录评估过滤条件。由于行式存储中数据是按行打包的，这种模式很高效。但ClickHouse的列式存储改变了游戏规则：

sql复制-- 典型WHERE查询示例
SELECT 
    user_name, 
    registration_date,
    last_login_ip
FROM user_events 
WHERE event_date > '2023-01-01'

这个查询的实际执行流程：

从磁盘读取user_name、registration_date、last_login_ip和event_date四列的全部数据
将所有数据加载到内存
逐行检查event_date条件
返回符合条件的行

当user_events表有100列而我们只需要其中4列时，WHERE会导致96列的不必要读取。我曾处理过一个实际案例：一个包含50列、10亿行的表，使用WHERE查询3列时消耗了12GB内存，而改用PREWHERE后降至800MB。

2.2 PREWHERE的列式优化

PREWHERE是ClickHouse针对其存储特点设计的智能过滤机制。仍以上述查询为例：

sql复制-- 优化后的PREWHERE查询
SELECT 
    user_name,
    registration_date,
    last_login_ip
FROM user_events
PREWHERE event_date > '2023-01-01'

执行流程差异：

仅读取event_date一列的数据
在内存中构建满足条件的行号位图（bitmap）
根据位图只提取user_name等三列中对应的行
组合结果返回

这种"两步走"策略在列数差异大的场景下优势明显。在我的压力测试中，对于包含200列的表，查询5列时PREWHERE比WHERE减少98%的磁盘IO。

3. 性能对比与量化分析

3.1 资源消耗对比实验

我设计了一个对照实验来展示两者的性能差异：

测试环境：

ClickHouse 22.8版本
16核CPU/64GB内存服务器
测试表：100列×1亿行，MergeTree引擎

测试用例：

sql复制-- 用例1：WHERE
SELECT col1, col2 FROM large_table WHERE col99 > 100;

-- 用例2：PREWHERE 
SELECT col1, col2 FROM large_table PREWHERE col99 > 100;

指标对比：

指标	WHERE	PREWHERE	优化幅度
读取数据量	18GB	210MB	98.8%↓
内存峰值	15GB	1.2GB	92%↓
执行时间	4.2s	0.7s	83%↓
CPU利用率	85%	35%	-

3.2 适用场景决策树

根据实战经验，我总结出过滤方式选择的决策流程：

表引擎是否为MergeTree系列？
- 否 → 必须使用WHERE
- 是 → 进入第2步
查询列是否包含大量非过滤列？
- 否（如SELECT过滤列）→ WHERE/PREWHERE差异不大
- 是 → 进入第3步
过滤条件是否具有高选择性（过滤后数据量<5%）？
- 是 → PREWHERE优势显著
- 否 → 测试两种方式性能

4. 高级技巧与实战经验

4.1 自动优化机制揭秘

ClickHouse的查询优化器会在特定条件下自动将WHERE转换为PREWHERE：

当过滤列是主键或分区键时
查询中不包含ARRAY JOIN或JOIN操作
未设置optimize_move_to_prewhere=0

但自动优化有局限性：

不会分析列的大小和分布
对复杂条件（如多个OR组合）判断保守

建议通过EXPLAIN语句验证执行计划：

sql复制EXPLAIN SELECT ... FROM ... WHERE ...

查看执行计划中是否出现"PREWHERE"字样。

4.2 混合使用场景的陷阱

虽然语法上不允许同时使用PREWHERE和WHERE，但以下写法会导致意外行为：

sql复制-- 反例：条件分散导致优化失效
SELECT * FROM table
WHERE col1 > 100
AND col2 IN (
    SELECT col2 FROM table2 PREWHERE col3 < 50
)

正确做法是将所有主表过滤条件集中：

sql复制-- 正例：统一过滤条件
SELECT * FROM table
PREWHERE col1 > 100
AND col2 IN (
    SELECT col2 FROM table2 WHERE col3 < 50
)

5. 特殊场景处理方案

5.1 低选择性过滤的优化

当过滤条件匹配超过50%数据时，PREWHERE可能反而更慢。这时可以：

强制禁用PREWHERE：

sql复制SET optimize_move_to_prewhere=0;
SELECT ... WHERE ...

使用分区裁剪：

sql复制SELECT ... FROM table
WHERE partition_column = value
AND other_column > 100  -- 这个条件会自动作为PREWHERE

5.2 多条件组合策略

对于复杂条件，性能优劣排序：

高选择性条件放前面
计算成本低的条件放前面
使用AND连接的多个条件应按照选择性降序排列

示例：

sql复制-- 较优写法
PREWHERE 
    date = today()  -- 高选择性、计算简单
    AND user_id > 1000  -- 中等选择性
    AND length(email) > 10  -- 计算成本高
    
-- 较差写法
PREWHERE
    length(email) > 10
    AND user_id > 1000
    AND date = today()

6. 引擎兼容性与未来演进

6.1 各引擎支持情况

引擎类型	PREWHERE支持	备注
MergeTree系列	完全支持	包括Replicated等变种
Log家族	不支持	TinyLog/StripeLog等
集成引擎	部分支持	Kafka/MySQL等有限支持
特殊引擎	不支持	Set/Join等内存表

6.2 版本演进趋势

从ClickHouse 21.x到23.x版本，PREWHERE的优化持续增强：

21.4：引入PREWHERE自动选择算法
22.1：支持JOIN查询中的部分PREWHERE下推
23.3：改进多条件PREWHERE的成本估算

未来可能的方向包括：

基于机器学习的过滤条件排序
向量化PREWHERE执行
分布式场景下的PREWHERE优化

在实际工作中，我建议每次升级后都重新测试关键查询的性能特征，因为优化器的行为可能发生变化。一个在22.8版本表现良好的PREWHERE查询，在23.x版本可能有更优的执行计划。