为什么 OLAP 需要专用库
业务库（OLTP）是为"按主键点查、写一笔记一笔"设计的，用它去跑"统计过去 30 天每个地区的日活趋势"这种全表扫描聚合，往往要扫几亿行、跑几十秒。分析型查询（OLAP）和事务型负载的读写模式完全不同，所以业界用专用库来扛分析场景，ClickHouse 就是其中最流行的开源选择之一。
它擅长在单台机器上对海量数据做亚秒级聚合，非常适合埋点日志、行为分析、实时报表这类"写得进、算得快"的场景。
本文核心知识点
- 列式存储只读需要的列，扫描量大减。
- MergeTreeClickHouse 的核心表引擎。
- 稀疏索引配合排序键实现快速定位。
- 物化视图预聚合，把实时查询变秒回。
列式存储到底快在哪
传统行式数据库把一行的所有字段存在一起；分析查询往往只用到其中两三个列（比如只要地区和日活），却要把整行整行读出来，大量带宽浪费在无关字段上。列式存储把同一列的数据集中存放，查询时只读涉及的列，还天然对同类数据做高压缩，扫描和 IO 都小一个量级。这就是 ClickHouse 聚合快的根本原因。
MergeTree 引擎与排序键
ClickHouse 最常用的表引擎是 MergeTree。建表时要指定 ORDER BY 排序键，数据按排序键有序写入后台的多个数据片段，后台再不断合并。查询条件命中排序键时，能跳过大量无关片段，这是它快的另一关键。
CREATE TABLE events (
ts DateTime, region String, uid UInt64, act String
) ENGINE = MergeTree
ORDER BY (region, ts);分区与稀疏主键索引
在排序键之外，还可以用 PARTITION BY 按天或按地区分区，查询时只扫命中的分区，把无关日期整块跳过。注意 ClickHouse 的主键索引是稀疏的：它不索引每一行，而是每隔一批数据记一个标记，配合有序存储已经足够快，索引体积极小。
实时聚合查询怎么写
日常分析就是各种 GROUP BY 聚合。ClickHouse 内置了丰富的聚合函数，配合列式存储，几亿行按地区、按小时分组统计也能很快返回。
SELECT toStartOfHour(ts) h, region, count()
FROM events
WHERE ts >= now() - INTERVAL 1 DAY
GROUP BY h, region
ORDER BY h;物化视图加速预聚合
对每次都要实时算的固定报表，别每次都扫全量。用物化视图在数据写入时就预聚合好，查询直接读预聚合结果，把"扫几亿行"变成"读几千行"。这是 ClickHouse 扛实时大屏的核心手段。
什么时候该上 ClickHouse
- 海量日志、埋点、行为数据的聚合分析 → 非常合适。
- 实时报表、大屏、趋势统计 → 用物化视图加速。
- 按主键频繁点查、强事务写 → 别用它，回业务库。
落地清单
- 按查询特征设计 ORDER BY 排序键，让过滤条件命中排序。
- 按时间或高频维度 PARTITION BY，减少扫描范围。
- 固定报表用物化视图预聚合，别每次全量扫。
- 它是 OLAP 专用库，别拿它当业务事务库用。