---

适用人群：大数据开发、数仓工程师、后端开发、面试备考

前言

在大数据实时分析、用户行为漏斗、日志检索、海量报表统计场景中，MySQL、PostgreSQL 早已力不从心，Elasticsearch 聚合性能瓶颈明显、资源开销巨大。而 ClickHouse 作为俄罗斯 Yandex 开源列式存储 OLAP 数据库，凭借毫秒级海量聚合、超高写入吞吐、极低资源占用，已成为神策分析、日志分析、电商漏斗、实时大屏的标配引擎。本文基于企业落地 PPT 全量整理，从零拆解：简介优缺点、场景选型、核心概念、单机集群部署、数据类型、全系列表引擎、SQL 高阶语法、副本分片集群、执行计划、建表规范、查询调优、物化视图实战，一文搞定面试 + 工作落地。

目录

1. ClickHouse 核心简介
2. ClickHouse 优缺点 & 适用场景
3. ClickHouse 与 ES 深度对比
4. ClickHouse 核心基础概念
5. 安装部署：单机 + 集群
6. 全量数据类型详解
7. 引擎精讲：数据库引擎 + 表引擎
8. ClickHouse 高阶 SQL 操作
9. 副本机制与高可用原理
10. 分片集群原理与实战配置
11. Explain 执行计划详解
12. 企业级建表优化规范
13. 语法优化 + 查询性能调优
14. 物化视图原理与案例实操
15. 面试高频总结

---

1 ClickHouse 核心简介

1.1 是什么

ClickHouse 是 Yandex 2016 年开源、C++ 编写的列式存储分析型 DBMS，主打 OLAP 在线分析处理，支持 SQL 实时查询、动态生成分析报表。

1.2 背景能力

• 底层支撑 YandexMetrica：全球第二大 Web 分析平台
• 承载 13 万亿 + 记录，每日处理 200 亿 + 事件
• 适配：用户行为分析、会话统计、多维度 SUM / 去重 / 百分比漏斗报表

---

2 ClickHouse 优缺点 & 适用场景

2.1 核心优点

1. 分布式架构，支持水平弹性扩容
2. 列式存储 + 高压缩，节省磁盘与 IO
3. 多核全资源并行计算，大查询吞吐拉满
4. 写入性能是 ES 5 倍，资源消耗更低
5. 查询性能平均是 ES 12.7 倍
6. 兼容标准 SQL、支持副本、分区、索引、异地部署
7. 硬件 & 人力成本低，上手简单易维护

2.2 缺点（选型必避坑）

1. 无完整事务支持，不适合 OLTP
2. 不支持高频单行增删改，只适合批量变更
3. 稀疏索引，不适合单行精准点查询
4. 高并发弱，官方建议单机 QPS 仅 100
5. 不擅长多表 JOIN，推荐宽表建模
6. 写入必须 1000 行以上批量，禁止逐行插入

2.3 适合场景

✅ 读多写少、实时多维分析报表✅ 大批量批次写入，数据写入后极少修改✅ 宽表、字段多、查询只取少量列✅ 无强事务、对数据一致性要求不高✅ 单张大表为主，聚合结果远小于原始数据

2.4 不适合场景

❌ 订单交易、支付等强事务 OLTP❌ 全文检索、模糊匹配优先业务❌ 超高并发接口、高频点查服务❌ 金融核心强一致性业务

---

3 ClickHouse 与 ES 深度对比

表格

对比维度	ClickHouse	Elasticsearch
OLAP 聚合能力	极强、速度快、资源省	较弱、大聚合易卡顿
写入性能	ES 的 5 倍，开销小	一般，大批量易 GC
查询性能	平均快 12.7 倍	依赖硬件，衰减明显
资源占用	低，同等业务成本更低	高，内存磁盘消耗大
稳定性	大批量导出无宕机风险	大量导出频繁 GC 易宕机
全文检索	弱、不推荐	原生极强
高并发查询	弱	强
学习成本	低，类 MySQL SQL	高，DSL 复杂

---

4 ClickHouse 核心基础概念

1. 列式存储：按列存数据，只加载查询列，IO 极低、压缩率高
2. 分片 Shard：大表水平拆分，分散多节点，实现扩容
3. 副本 Replica：同分片多节点备份，保障高可用
4. 向量化执行：按向量批量计算，CPU 利用率极高
5. 分区 Partition：按时间 / 维度拆分，查询自动裁剪无关分区
6. 表引擎：CK 核心，决定存储、索引、合并、副本、聚合逻辑
7. 稀疏索引：MergeTree 默认索引粒度 8192，跳过无效数据块

---

5 安装部署：单机 + 集群

5.1 单机部署

启动服务

bash

运行

service clickhouse-server start

提示进程已存在：代表服务正在运行。

核心路径与端口

• 配置文件：/etc/clickhouse-server/config.xml
• 工作目录：/var/lib/clickhouse/user_files
• 端口：8123
• 客户端连接：clickhouse-client

查看端口监听

bash

运行

netstat -nltp | grep 8123

5.2 集群部署

• 依赖 Zookeeper 做分片、副本元数据同步
• ClickHouse 集群是表级别，企业常用：3 分片 2 副本 6 节点架构
• 官方文档：https://clickhouse.com/docs/zh/getting-started/tutorial

---

6 全量数据类型详解

6.1 整型

有符号：Int8/Int16/Int32/Int64/Int128/Int256无符号：UInt8/UInt16/UInt32/UInt64/UInt128/UInt256

6.2 浮点型

Float32、Float64

⚠️ 严禁存金额、汇率，存在精度丢失示例：1.0-0.9 = 0.09999999999999998

6.3 布尔类型

19.4 之前无独立 Bool，用 UInt8(0/1) 替代；高版本支持原生 BOOL。

6.4 Decimal 高精度类型

• 语法：Decimal(P,S)

• • P：总有效位数 1~38
  • S：小数位数 0~P

• 简写：Decimal32(s)、Decimal64(s)、Decimal128(s)

✅ 金额、利率、汇率必须用 Decimal

6.5 字符串类型

• String：任意长度无限制
• FixedString(N)：固定长度，不足补空字节，超长抛异常

6.6 枚举类型

Enum8 / Enum16，字符串映射整型存储，节省空间

sql

CREATE TABLE t_enum (
    x Enum8('hello' = 1, 'world' = 2)
) ENGINE = TinyLog;

6.7 时间类型

Date / Date32 / DateTime / DateTime32 / DateTime64（亚秒级）

6.8 数组类型

Array(T)，适合多标签、多属性业务存储

---

7 引擎精讲：数据库引擎 + 表引擎

引擎大小写敏感，决定数据存储、索引、并发、副本、合并规则

7.1 数据库引擎

• 默认：Atomic
• 常用：MySQL、PostgreSQL、SQLite、Replicated

sql

-- 映射远程MySQL库
CREATE DATABASE db_mysql 
ENGINE = MySQL('127.0.0.1:3306','test','root','123456');

7.2 表引擎分类

7.2.1 日志引擎（仅测试）

TinyLog / Log / StripeLog

• 磁盘存储、末尾追加
• 无索引、不支持并发、不支持增删改
• 宕机易数据损坏，禁止上生产

7.2.2 Memory 引擎

• 数据存内存，重启丢失
• 无索引、读写无阻塞
• 适合临时表、中间计算、测试

7.2.3 MergeTree 生产核心引擎

CK 最强引擎，对标 MySQL InnoDB，支持分区、主键、二级索引、副本、TTL

标准建表示例

sql

create table t_order_mt(
    id UInt32,
    sku_id String,
    total_amount Decimal(16,2),
    create_time Datetime
) engine =MergeTree 
partition by toYYYYMMDD(create_time)
primary key (id)
order by (id,sku_id);

核心参数

1. partition by 分区

• • 缩小扫描范围，支持并行查询
  • 后台 10~15 分钟自动合并，可手动 optimize table xxx final

1. primary key 主键

• • 不做唯一约束，仅稀疏索引
  • 必须是 order by 字段前缀

1. order by 排序键

• • 必选，分区内数据有序；无主键时排序键即主键

1. 跳数索引（二级索引）

sql

INDEX a total_amount TYPE minmax GRANULARITY 5

作用：跳过无效数据区间，大幅减少 IO5. TTL 生命周期

• 列 TTL：字段到期置空
• 表 TTL：整行过期自动清理

7.2.4 ReplacingMergeTree 去重引擎

• MergeTree 变种，按排序键自动去重
• 保留版本字段值最大的一行
• 仅分区内去重，不跨分区
• 合并时才去重，无法实时强唯一

7.2.5 SummingMergeTree 预聚合引擎

• 自动按维度累加数值字段
• 适合只看汇总、不需要查明细的报表场景
• 后台合并自动聚合，降低查询开销

---

8 ClickHouse 高阶 SQL 操作

8.1 ALTER 操作

仅支持 MergeTree / Replicated / Distributed

sql

-- 新增列
ALTER TABLE t_order ADD COLUMN browser String AFTER create_time;
-- 删除列
ALTER TABLE t_order DROP COLUMN browser;
-- 分区清空列数据
ALTER TABLE t_order CLEAR COLUMN total_amount IN PARTITION 20200601;

8.2 Insert 写入

1. 多行批量插入
2. 表导表：insert into t1 select * from t2
3. 文件导入：FROM INFILE

规范：千行以上批量写入，写入前预排序

8.3 Update / Delete 突变 Mutation

CK 增删改是重型操作，无事务、重建分区，性能差

sql

-- 删除
alter table t_order delete where sku_id ='sku_001';
-- 更新
alter table t_order update total_amount=2000 where id=102;

建议：禁止频繁小批量变更

8.4 特色查询语法

PREWHERE 优化

仅 MergeTree 支持，先过滤再读列，比 Where 性能高很多

sql

select id,sku_id from t_order_mt prewhere sku_id ='sku_001';

GROUP BY 增强

支持 with rollup / with cube / with totals 自动小计、总计、维度组合聚合

WITH 子句

支持常量、CTE、标量子查询，提升 SQL 可读性

数据导出

bash

运行

clickhouse-client --query "select * from t_order" --format CSVWithNames > /opt/data/rs1.csv

---

9 副本机制与高可用原理

1. 作用：节点宕机不丢数据、业务无感知
2. 依赖 Zookeeper 同步写入日志
3. 只同步数据，不同步表结构，所有副本需手动建表
4. 引擎：ReplicatedMergeTree 指定 ZK 路径 + 副本名称

---

10 分片集群原理与实战配置

10.1 核心概念

• 分片：数据水平拆分，解决单节点存储瓶颈
• 副本：同分片多节点高可用
• Distributed 引擎：逻辑分布式表，自动路由分片、合并结果

10.2 集群部署步骤

1. config.xml 配置分片、副本、ZK 集群
2. ON CLUSTER 建本地表，自动同步副本
3. 创建 Distributed 分布式表，指定分片键
4. 业务只操作分布式表，底层自动路由

---

11 Explain 执行计划详解

常用模式：

• AST：查看语法树
• SYNTAX：查看优化后 SQL
• PLAN：执行计划、索引使用情况
• PIPELINE：执行流水线流程

用途：慢查询定位、索引失效排查、语法优化校验

---

12 企业级建表优化规范

1. 时间字段优先 DateTime/Date，禁止字符串存时间
2. 禁用滥用 Nullable，额外存储、无法索引，用默认值代替空
3. 分区粒度适中：按天分，亿级数据分区控制 10~30 个
4. 排序键 / 索引键：查询高频字段放前面，基数过大不做索引
5. 默认 index_granularity=8192，非必要不修改
6. 合理配置 TTL，自动清理过期数据
7. 写入控制：每秒 2~3 次，每次 2w~5w 行，避免合并跟不上写入

---

13 语法优化 + 查询性能调优

13.1 内置语法优化

1. count() / count(*) 直接读取元数据，极速
2. 谓词下推：Having 无修饰时自动下推到 Where
3. 聚合计算外推，减少数据遍历
4. 三元运算自动转 multiIf 提升效率

13.2 查询优化十大技巧

1. Prewhere 替代 Where，性能提升 10 倍
2. SAMPLE 数据采样，快速估算分析
3. 列裁剪 + 分区裁剪，禁止 select *
4. OrderBy 必须搭配 Where + Limit
5. 减少虚拟列计算，前置到业务或预建字段
6. uniqCombined 替代 distinct，去重性能提升 10 倍 +
7. 批量写入先排序，减少分区碎片
8. 禁止大表 JOIN，优先宽表设计
9. 用 ReplacingMergeTree + GroupBy 保证最终一致性
10. 严控 CPU，超过 70% 易查询超时

---

14 物化视图原理与案例实操

14.1 普通视图 vs 物化视图

• 普通视图：只存 SQL，查询实时查原表，无性能提升
• 物化视图：持久化预聚合结果，相当于一张物理表，查询秒级

14.2 优缺点

✅ 优点：预计算、查询极快、增量自动同步❌ 缺点：源表历史变更不联动、多视图写入开销大

14.3 实战建表示例

sql

CREATE MATERIALIZED VIEW hits_mv 
ENGINE=SummingMergeTree 
PARTITION BY toYYYYMM(EventDate) 
ORDER BY (EventDate, UserID) 
AS SELECT 
    UserID, EventDate,
    count(URL) as ClickCount,
    sum(Income) AS IncomeSum 
FROM hits_test
GROUP BY UserID,EventDate;

建议：不使用 POPULATE，创建后手动导入历史，只同步增量

---

15 面试高频总结

1. ClickHouse 适用什么场景？不适用什么场景？
2. MergeTree 分区、主键、排序键区别？
3. ReplacingMergeTree 去重原理、能否跨分区？
4. SummingMergeTree 聚合机制？
5. Prewhere 和 Where 区别与优化原理？
6. 副本与分片集群原理？Distributed 引擎作用？
7. 为什么不建议用 Nullable？
8. 物化视图和普通视图区别？
9. ClickHouse 为什么不适合高并发和多表 JOIN？
10. 日常建表和查询有哪些优化手段？