考察点
这是 OLAP 方向几乎必问的开场题，面试官想确认你是真的用过 ClickHouse 还是只背过名词。重点不在罗列四个概念，而在讲清每个机制解决了什么瓶颈、彼此怎么配合。追问通常往细节走：稀疏索引为什么能稀疏、物化视图和投影怎么继续加速、什么场景下 ClickHouse 反而不快。
参考答案
列式存储：把 IO 砍到最小
分析型查询的特点是「行多列少」：一张几十列的宽表，一条查询可能只用 3 列。行存要把整行读出来再挑字段，列存只读用到的列文件，IO 量直接降一个数量级。而且同一列数据类型相同、取值相似，压缩率非常高——ClickHouse 默认 LZ4，对重复度高的列（状态码、城市 ID 这类低基数字段）经常能压到原始大小的十分之一以下，还可以换 ZSTD 换更高压缩比。压缩率高意味着一次磁盘读能带回更多有效数据，IO 又被进一步放大收益。列文件里还支持按列配 codec，比如时间戳列用 DoubleDelta、单调递增列用 Gorilla，这是行存做不到的。
稀疏主键索引：不是 B+ 树
很多人拿 InnoDB 的 B+ 树来套 ClickHouse，会被追问卡住。MergeTree 的数据按主键（ORDER BY 的列）排序后切成一个个 granule，默认 8192 行一个。索引只为每个 granule 存一条主键值的标记（mark），十万行的数据可能只有十几条索引项，整个索引常驻内存。查询时先拿查询条件在内存索引里二分，圈出可能命中的 granule 区间，再按 mark 文件定位到列文件里的具体偏移去读。
稀疏索引能成立的前提是「数据按主键物理有序」加上「分析查询本来就按范围扫」。它不追求精确定位到行，追求的是把 1 亿行缩小到几个 granule、几十万行，剩下的靠扫。所以主键设计极其关键：把高频过滤字段（日期、租户 ID、事件类型）放在 ORDER BY 前面，过滤效率天差地别。主键不唯一、不去重，这点也要说清楚。
向量化执行：榨干 CPU
数据读进来之后，ClickHouse 不是一行行处理，而是按列成批处理：一次对一个数组（列的一段，通常几千个值）做过滤、聚合。批处理的好处是 CPU 流水线不断流、分支预测命中率高，还能直接用 SIMD 指令一条指令算多个值。配合它对聚合函数的大量手工优化（比如 GroupBy 针对低基数 key 用不同的哈希表实现），单核就能跑出每秒几亿行的扫描速度。这也是为什么 ClickHouse 单机就能打很多分布式引擎——它先把单机的每个环节都做到了极致。
MergeTree：写入快的秘密在 LSM 思路
写入快靠的是「追加 + 后台合并」。一次 INSERT 生成一个新的 part 目录，数据在 part 内排序、写列文件，写完即对查询可见。没有行级更新的开销，攒批写十万行就是一次顺序写。后台 merge 线程持续把小 part 合并成大 part（类似 LSM-tree 的 compaction），控制 part 数量，同时完成去重（ReplacingMergeTree）、预聚合（AggregatingMergeTree）这类引擎特有逻辑。
代价也明显：不适合高频小批量写入（part 太多会报 Too many parts），不适合行级更新删除（UPDATE/DELETE 是重量级 mutation，重写整个 part）。面试官追问「ClickHouse 的短板」时，这两点加上 join 能力弱、不擅长高并发点查，就是标准答案。
串起来讲
一句话总结整条链路：写入是顺序落 part 所以快；读取时列存只取所需列、稀疏索引把扫描范围缩到几个 granule、压缩让单位 IO 带出更多数据、向量化让 CPU 全速跑——每一层都在为「大范围扫描」这一个目标服务，这就是它读写都快的完整逻辑。
可能的追问
- 稀疏索引和跳数索引（minmax/set/bloom_filter）什么区别？—— 稀疏主键索引靠排序缩小范围；跳数索引是 granule 级的辅助结构，对非排序列做粗过滤，bloom_filter 适合高基数等值判断，但只能判断「肯定没有」，命中的 granule 还得读出来验证。
- 为什么小批量高频写入会出问题？—— 每次 INSERT 一个 part，part 数量暴涨后台 merge 跟不上，触发 Too many parts 阈值拒绝写入。正确姿势是客户端攒批，单次几万到几十万行，间隔几秒以上。
- 亿级表点查某一行快不快？—— 不快。ClickHouse 没有真正的行级索引，点查也要扫 granule 级别的数据，高并发点查应该上 Doris 或者 KV。