先说结论

ClickHouse 的核心优势是对海量数据进行高吞吐写入、列裁剪、压缩、扫描与聚合；不足是高频单行更新、强事务、复杂点查、超高查询并发和跨行约束并非其主要设计目标。

技术选型不能只回答“ClickHouse 快”，而要说明它在哪类负载下快，以及为了这种速度放弃了什么。

ClickHouse 的定位

ClickHouse 是面向 OLAP 的列式数据库，适合事件、日志、指标、用户行为和宽表分析。典型查询会读取少量列、扫描大量行，再进行过滤、分组和聚合。

它并不是 MySQL 的直接替代品。MySQL 擅长高并发短事务、点查和约束；ClickHouse 擅长批量写入和大规模分析。实际系统经常让两者分别承担交易与分析职责。

优势一：列式存储减少无关 IO

行式存储把一行字段放在一起，查询少数列时仍可能读取其他字段。列式存储把同一列连续保存，分析查询只读取需要的列。

SELECT tenant_id, count(), sum(amount)
FROM orders
WHERE event_date >= today() - 7
GROUP BY tenant_id;

即使订单表有几十个字段，这条查询主要读取日期、租户和金额列。列裁剪可以显著降低磁盘读取、解压和内存传输。

优势二：压缩率高

同一列中的数据类型一致、取值分布相近，通常更容易使用 Delta、DoubleDelta、Gorilla、字典和通用压缩算法。更高压缩率意味着更少磁盘空间与 IO，但压缩编码应根据数据分布选择，不能盲目叠加。

LowCardinality(String) 对重复较多的字符串采用字典编码，常用于状态、渠道和地区；对几乎不重复的 UUID 使用它反而可能增加开销。

优势三：向量化执行

ClickHouse 不是逐行解释每个表达式，而是以数据块为单位处理一批值，减少函数调用和分支开销，并利用 CPU 缓存和 SIMD 能力。

向量化对扫描、过滤和聚合非常有效，但如果查询只读取一行，启动流水线和调度线程的固定开销不一定比 OLTP 数据库更低。

优势四：并行执行能力强

单条查询可以使用多个线程并行读取不同数据片段、执行聚合，再合并结果。分布式表还能将查询下推到多个分片。

这也是 ClickHouse 单查询很快却不一定适合超高并发的原因：每个查询可能主动占用大量 CPU 和内存，多条重查询同时运行会快速争抢资源。

优势五：MergeTree 适合追加写

批量写入形成不可变 Part，后台再合并。写入路径避免频繁原地随机修改，适合日志和事件流持续追加。

稀疏主键索引、分区裁剪、数据跳数索引和排序键可以跳过大量无关 Granule。只要表结构与查询模式匹配，就能用较小索引管理海量数据。

优势六：丰富的分析函数

ClickHouse 内置大量聚合、数组、窗口、漏斗、留存、近似去重和分位数函数。许多分析可以直接在数据库完成，减少数据搬运。

近似算法以少量误差换取显著资源节省，适合监控和趋势分析；账务等需要绝对精确的场景必须选择精确函数并验证溢出与精度。

优势七：数据生命周期管理

通过分区与 TTL，可以删除、移动或聚合过期数据。例如近期数据保存在高速磁盘，历史数据迁移到低成本存储。TTL 操作通常通过后台 Merge 落地，并非到期瞬间立刻物理删除。

不足一：不擅长高频单行更新和删除

MergeTree 的 Part 不可变，UPDATE/DELETE Mutation 往往需要重写数据块。大量小更新会制造合并和 IO 压力。

ClickHouse 新版本提供轻量删除等能力，但仍不意味着可以按 OLTP 模式每秒更新大量随机行。频繁变化的当前状态通常保留在 MySQL、Redis 或专门状态存储中，再把事件同步到 ClickHouse。

不足二：事务能力与 OLTP 不同

ClickHouse 的核心目标不是跨多行、多表的高并发 ACID 事务。不能依赖传统关系数据库式外键、唯一约束和复杂事务来保护业务不变量。

订单扣款、库存扣减等核心流程应由事务数据库负责，分析数据通过 CDC 或消息队列进入 ClickHouse。

不足三：点查和极低延迟不一定占优

ClickHouse 的稀疏索引适合跳过大块数据，而不是像 B+Tree 一样逐行精确定位。单行主键点查、每次只返回一条记录且并发极高时，MySQL、KV 数据库可能更适合。

不足四：高并发短查询能力有限

ClickHouse 擅长把资源集中给少量重查询。每条查询可能启动多个线程、分配聚合状态并读取大量数据。几百到几千个分析查询同时进入，会造成 CPU、内存、磁盘和网络争用。

可以通过配额、并发限制、查询队列、缓存、预聚合和副本分流改善，但不能把资源密集型 OLAP 查询当作轻量 API 点查无限扩展。

不足五：表设计强依赖查询模式

排序键一旦选择不当，查询会读取大量无关数据。修改排序键通常需要重建或迁移表。ClickHouse 倾向宽表和面向查询建模，数据冗余、同步与回填流程需要额外治理。

不足六：JOIN 使用需要控制

ClickHouse 支持多种 JOIN，但大表之间无过滤 JOIN 会消耗大量内存和网络。高频查询常通过宽表、字典、物化视图或预聚合减少实时 JOIN。

是否反范式化要看维度更新频率和一致性要求。宽表能减少查询成本，却增加数据重复和回填难度。

不足七：运维复杂度

分片、副本、Keeper、分布式 DDL、数据迁移、Part 数量、Merge 队列和磁盘容量都需要持续监控。规模扩大后，数据倾斜和热点分片会显著影响稳定性。

适合的场景

  • 用户行为、埋点、日志和指标分析。
  • 广告、推荐和运营报表。
  • 大规模明细查询与多维聚合。
  • 时序事件、风控事件和审计事件分析。
  • 从 MySQL CDC 构建近实时分析库。

不适合直接承担的场景

  • 支付、库存和订单核心事务。
  • 高频单行增删改。
  • 依赖外键与复杂约束的数据写入。
  • 超高并发、每次只查询单行的在线接口。
  • 要求跨行更新严格原子提交的业务。

常见问题

追问 1：ClickHouse 为什么查询快？

列式读取减少无关 IO，同列数据压缩率高；向量化按批处理，排序键和稀疏索引跳过数据；单查询还可使用多线程和多分片并行。

追问 2：ClickHouse 能替代 MySQL 吗？

通常不能。MySQL 服务交易事务和高并发点查，ClickHouse 服务分析扫描。常见架构是 MySQL 作为事实源，通过 Binlog/CDC 同步到 ClickHouse。

追问 3：ClickHouse 支持 UPDATE 和 DELETE，为什么还说不适合更新？

支持功能不代表适合高频使用。Mutation 往往通过重写不可变数据片段完成，成本与受影响数据量相关，无法等同于 B+Tree 的行级原地更新路径。

追问 4：宽表一定比 JOIN 好吗？

不一定。宽表降低查询 JOIN 成本，但会造成重复、更新同步和回填复杂度。维度稳定且读远多于写时适合冗余；高频变化维度可能更适合字典或受控 JOIN。

追问 5：什么时候不应该选择 ClickHouse？

当核心负载是短事务、随机单行更新、强约束、超高并发点查，或数据规模不大且普通数据库已满足需求时，引入 ClickHouse 只会增加系统复杂度。