一、为什么需要 ClickHouse：OLTP 与 OLAP 的冲突

MySQL / PostgreSQL 擅长的是 OLTP（联机事务处理），行存、强事务、点查写入快。BI / 监控 / 埋点分析需要的是 OLAP（联机分析处理），列存、高吞吐扫描、聚合快。两者设计目标不同，硬用 MySQL 做分析会遇到三大瓶颈：

二、核心概念速览

ClickHouse 的名词和 MySQL 不一样，先把概念对齐：

注意：ClickHouse 的 PRIMARY KEY 不保证唯一，它只是声明排序键并构建稀疏索引。真正的去重要用 ReplacingMergeTree 或在写入前完成。

三、列式存储：为什么聚合查询这么快

列式存储是 ClickHouse 快的根本原因。假设一条订单记录有 50 个字段，分析查询通常只关心 order_amount、province、dt 三个字段：

1
2

行存读取：把整行 50 个字段全部读到内存，再丢弃 47 个
列存读取：只把 order_amount、province、dt 三列加载到内存

四、MergeTree 表引擎：数据的物理组织

MergeTree 是 ClickHouse 的默认与核心引擎。建表示例：

1
2
3
4
5
6
7
8
9
10
11
12

CREATE TABLE order_events
(
    dt          Date,
    ts          DateTime,
    order_id    UInt64,
    user_id     UInt64,
    province    LowCardinality(String),
    amount      Decimal(18, 2)
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(dt)
ORDER BY (province, dt, order_id);

关键设计：

• PARTITION BY：按月份把数据拆到不同目录，删除旧分区时只需删目录，极快。
• ORDER BY：决定 Part 内部物理顺序，是稀疏索引的依据，也是查询剪枝的关键。
• 不可变 Part：每次批量写入产生一个 Part，后续由后台线程合并，写入性能极高。
• 稀疏索引：每 8192 行（一个 Granule）记录一次边界值，索引体积小，适合顺序扫描。

五、分区与排序键：查询剪枝的艺术

同样的数据，不同的排序键，查询性能可能差几十倍。优秀的设计遵循：

1
2
3

-- 常见埋点日志表设计
ORDER BY (app_id, event_type, dt, user_id);
PARTITION BY toYYYYMMDD(dt);

这样 WHERE app_id = 'xxx' AND event_type = 'pay' AND dt >= '2026-10-01' 能同时命中分区剪枝和索引剪枝。

六、向量化执行与 SQL 解析

ClickHouse 的执行引擎是向量化（Vectorized）的：数据以块（Block）为单位处理，每列用紧凑数组存储，函数调用批量作用在数组上。相比传统的”一次处理一行”的火山模型，向量化大幅减少虚函数调用和缓存失效。

1
2
3
4
5
6
7
8
9
10

SELECT 
    province,
    count() AS order_count,
    sum(amount) AS total_amount,
    avg(amount) AS avg_amount
FROM order_events
WHERE dt >= today() - 7
GROUP BY province
ORDER BY total_amount DESC
LIMIT 100;

对于这条查询，ClickHouse 只会读取 dt、province、amount 三列，按 Granule 批量过滤、分组、聚合，最后在节点间做二次聚合。

七、物化视图与投影：空间换时间

物化视图（Materialized View）是 ClickHouse 里的”预聚合”利器。你可以为原始明细表建立一张汇总表，写入明细时自动把聚合结果同步过去：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

-- 1. 创建目标预聚合表
CREATE TABLE order_events_by_province
(
    dt       Date,
    province LowCardinality(String),
    pv       UInt64,
    amount   AggregateFunction(sum, Decimal(18, 2))
)
ENGINE = SummingMergeTree()
ORDER BY (dt, province);

-- 2. 创建物化视图，写入时自动聚合
CREATE MATERIALIZED VIEW mv_order_events_by_province
TO order_events_by_province
AS SELECT
    dt,
    province,
    count() AS pv,
    sumState(amount) AS amount
FROM order_events
GROUP BY dt, province;

查询时直接查 order_events_by_province 就能得到 province 维度的聚合结果，避免扫描明细。

八、MergeTree 家族与典型引擎

MergeTree 不是单一引擎，而是一个家族。根据业务场景选引擎，能少走很多弯路：

九、ClickHouse 与 Elasticsearch / Doris / StarRocks 怎么选

一句话：日志检索选 Elasticsearch，复杂数仓建模选 Doris/StarRocks，宽表聚合和高吞吐分析选 ClickHouse。

十、生产避坑清单

总结

ClickHouse 的设计哲学很清晰：用列式存储减少 I/O，用稀疏索引和分区做剪枝，用向量化执行压榨 CPU，用不可变 Part 换取极致写入吞吐。它不是万能数据库，但在”大宽表 + 海量数据 + 复杂聚合”的分析场景里几乎没有对手。掌握好排序键、分区键、MergeTree 家族与物化视图这四条主线，再结合生产避坑清单，就能把 ClickHouse 稳定地跑在监控、埋点、BI 数仓的第一线。

下一篇可以沿着”ClickHouse 集群分片与副本部署”或”ClickHouse 接入 Kafka/Flink 实时数仓”继续深入——把”算”和”存”真正打通，实时分析才算落地。