
大家好，我是数据库小学妹 👋

上个月，一家零售企业的客户问我。他们的报表系统越跑越慢，按地区和月份汇总一次要八分多钟。

我查了执行计划。索引用了。JOIN也优化了。但扫描的数据量就是那么大。一千万行数据，按地区、按产品、按时间维度汇总，MySQL的行式存储天生不擅长这种场景。

后来引入了ClickHouse做分析。同一个查询，从八分多钟降到两秒。差距不是一个量级。

今天我把列式存储的原理、ClickHouse的核心引擎、和MySQL的实际对比写出来。朋友，如果你的报表也越跑越慢，这篇或许能给你一个新思路。

---

## 行式存储为什么不适合做报表？

先看MySQL是怎么存数据的。

```
行式存储：
行1: [id=1, name=张三, region=华东, amount=100, date=2026-01-01]
行2: [id=2, name=李四, region=华南, amount=200, date=2026-01-02]
行3: [id=3, name=王五, region=华东, amount=150, date=2026-01-03]
...
```

所有列存在一起。读一行很快。但如果只算amount的总和呢？MySQL必须把每一行的所有列都读进内存，然后从中提取amount字段。其他列（name、region、date）也读了，但没用到。IO浪费了。数据量小时无所谓。一千万行时，这个问题被放大了无数倍。

**行式存储的设计目标是OLTP（在线事务处理）。** 它的优势是增删改快，单行查询快，事务支持好。报表分析不是它的主场。

## 列式存储是怎么做到快的？

ClickHouse用的是列式存储。同一个列的数据存在一起。

```
列式存储：
id列:     [1, 2, 3, 4, 5, ...]
name列:   [张三, 李四, 王五, 赵六, ...]
region列: [华东, 华南, 华东, 华北, ...]
amount列: [100, 200, 150, 300, ...]
date列:   [2026-01-01, 2026-01-02, ...]
```

执行`SELECT SUM(amount)`时，只需要读amount这一列。其他列完全不碰。IO量直接减少了N倍（N是列数）。

这还不是全部。列式存储还有两个杀手锏。

**数据压缩。** 同一列的数据类型相同，值域相近，压缩率极高。amount列全是数字，region列重复值多。列存压缩后通常只有行存的1/5到1/10。

```
压缩率对比（同一份数据）：
行式存储（MySQL InnoDB）：约 12GB
列式存储（ClickHouse）：  约 2.4GB
压缩比：5:1
```

**向量化执行。** 传统数据库一行一行算。ClickHouse一批一批算。这里面的关键是CPU的SIMD指令。

SIMD全称Single Instruction Multiple Data。单指令多数据。普通CPU指令一次处理一个值。SIMD指令一次处理8到16个值。ClickHouse把查询编译成向量化算子，每个算子直接调用SIMD指令。

```
传统执行（逐行）：
for row in rows:
    result += row.amount  ← 每次处理1个值

向量化执行（批量）：
result = SIMD_SUM(amount_chunk)  ← 每次处理8-16个值
```

我一开始不理解这有什么用。后来我用perf看了ClickHouse的执行profile，发现SUM操作走的是AVX2指令集，一个循环处理256位数据。64位的DECIMAL值一次能算4个。这就是为什么列存的SUM能比行存快几十倍。数据挨在一起，CPU可以批量加载到向量寄存器里，一条指令搞定。

但向量化加速有个前提：数据必须连续。行式存储里，amount字段和其他列混在一起，CPU要先跳过无关列才能取到数据。列式存储里，amount值连续存放，CPU直接批量加载。列存和向量化是天生一对。

向量化的加速效果取决于CPU。支持AVX2指令集的CPU，向量化SUM可以快4到8倍。

理解了列式存储和向量化，再来看ClickHouse的表引擎就顺了。ClickHouse有很多表引擎，MergeTree家族是最核心的。MergeTree的工作原理是：把数据按主键排序后分成多个"part"（数据块），每个part独立压缩存储，查询时只扫描相关的part。

```
MergeTree数据组织：
part_1: [主键范围 1-10000]   ← 压缩存储，有索引
part_2: [主键范围 10001-20000]
part_3: [主键范围 20001-30000]
...

查询 WHERE id BETWEEN 5000 AND 15000：
→ 只需扫描 part_1 和 part_2
→ part_3 及之后的part跳过
```

MergeTree有两个核心特性。

**主键索引（稀疏索引）。** 不是B+树，而是一个稀疏的标记。每隔一定行数（默认8192行，ClickHouse叫index_granularity）记录一个主键值和它对应的mark文件偏移。查询时先查索引标记，通过mark文件定位到具体的数据块，只读那个块。8192这个默认值和ClickHouse的存储设计有关——每个granule存8192行数据，一个索引标记对应一个granule，索引体积小但足以定位。如果有大量点查（WHERE id = xxx）的需求，可以调小index_granularity来加密索引，代价是索引体积变大。

**数据合并（Merge）。** 新写入的数据先放到一个小part。后台自动把小part合并成大part。合并时重新排序、去重、压缩。这个过程对用户透明。

创建一个MergeTree表：

```sql
CREATE TABLE orders (
    order_id UInt64,
    customer_id UInt64,
    region String,
    product_id UInt32,
    amount Decimal(12, 2),
    order_date Date,
    status UInt8
) ENGINE = MergeTree()
ORDER BY (order_date, region, customer_id)  -- 排序键（也是主键）
PARTITION BY toYYYYMM(order_date);          -- 按月分区
```

ORDER BY在这里不是排序操作，是定义主键（排序键）。数据按这个顺序存储，决定了查询能用哪些索引。ORDER BY的字段顺序很关键——把查询最常用的过滤条件放前面，这样WHERE条件才能命中索引。我一开始把customer_id放第一位，后来发现大多数查询都是按时间范围过滤，改成(order_date, region, customer_id)后，扫描的granule少了很多。

PARTITION BY把数据按月分成独立的分区。查询时如果带了时间范围条件，ClickHouse会先用分区裁剪（partition pruning）跳过不相关的分区，只扫描目标分区。查三个月的数据就只读三个分区，不碰其他月份。分区粒度要权衡：太细（按天）会导致part数量太多，Merge压力大；太粗（按年）裁剪效果差。按月分区是比较稳妥的折中。

## 实际对比：同一个查询，MySQL vs ClickHouse

准备同样的数据。一千万条订单记录。

**MySQL（行式存储）：**

```sql
-- MySQL 表结构
CREATE TABLE orders (
    order_id BIGINT PRIMARY KEY,
    customer_id BIGINT,
    region VARCHAR(20),
    product_id INT,
    amount DECIMAL(12,2),
    order_date DATE,
    status TINYINT,
    INDEX idx_date_region (order_date, region)
) ENGINE=InnoDB;

-- 查询：按地区和月份汇总销售额
SELECT region,
       DATE_FORMAT(order_date, '%Y-%m') AS month,
       COUNT(*) AS order_count,
       SUM(amount) AS total_amount
FROM orders
WHERE order_date >= '2026-01-01'
  AND order_date < '2027-01-01'
GROUP BY region, DATE_FORMAT(order_date, '%Y-%m')
ORDER BY month, region;
```

执行结果：

```
12 rows in set (8 min 34 sec)
```

8分34秒。用了索引，但GROUP BY需要全表扫描符合条件的数据。

**ClickHouse（列式存储）：**

```sql
-- ClickHouse 表结构
CREATE TABLE orders (
    order_id UInt64,
    customer_id UInt64,
    region String,
    product_id UInt32,
    amount Decimal(12, 2),
    order_date Date,
    status UInt8
) ENGINE = MergeTree()
ORDER BY (order_date, region)
PARTITION BY toYYYYMM(order_date);

-- 同样的查询
SELECT region,
       toYYYYMM(order_date) AS month,
       count() AS order_count,
       sum(amount) AS total_amount
FROM orders
WHERE order_date >= '2026-01-01'
  AND order_date < '2027-01-01'
GROUP BY region, month
ORDER BY month, region;
```

执行结果：

```
12 rows in set. Elapsed: 2.145 sec.
Processed 10.00 million rows, 120.00 MB
```

2.1秒。快了约240倍。

为什么差距这么大？

| 维度 | MySQL InnoDB | ClickHouse MergeTree |
|------|-------------|---------------------|
| 存储方式 | 行式 | 列式 |
| 查询扫描量 | 读取整行（所有列） | 只读取查询涉及的列 |
| 数据压缩 | 无/低 | 高压缩比（5:1） |
| 执行方式 | 逐行 | 向量化批量 |
| IO量 | 约2.5GB | 约120MB |
| 用时 | 8分34秒 | 2.1秒 |

## 但ClickHouse不是万能的

我用了一段时间ClickHouse后，发现它有几个明显的短板。

**不适合高频单行更新。** ClickHouse的UPDATE是异步的重写操作。不是原地的行级修改。执行一条UPDATE，它要重写整个数据part。更新频率高会导致Merge永远追不上写入。

```sql
-- ClickHouse的UPDATE（异步重写，不是原地修改）
ALTER TABLE orders UPDATE amount = 600 WHERE order_id = 1;
-- MySQL是原地修改，ClickHouse是标记旧行删除+插入新行
-- 下次Merge时才会真正清理
```

我在一个电商项目里踩过这个坑。运营同事要频繁修改订单状态，每改一条就触发一次异步重写。上线两周后，小part越来越多，后台Merge跟不上写入速度，查询时要扫大量小part，性能反而变差。后来我把高频变更的字段留在MySQL，只把最终状态同步到ClickHouse，问题才解决。

**不支持事务。** ClickHouse没有ACID事务。不能做并发写入的一致性保证。它的设计假设是：数据批量写入后基本不变。如果往ClickHouse并发写入同一批数据，没有任何机制保证一致性。所以写入端要做好幂等设计。

**JOIN能力有限。** ClickHouse能做JOIN，但实现方式和MySQL不同。它默认用hash join，把右表整个加载到内存里构建哈希表。右表小的时候没问题。右表一大就容易OOM。虽然可以通过`join_algorithm`参数选择`partial_merge_join`来控制内存，但性能会打折扣。复杂的多表关联查询，还是MySQL更擅长。ClickHouse的强项是单表聚合分析，不是多表关联。

我一开始以为ClickHouse能完全替代MySQL。结果上线后发现它不是万能的——单行查询不擅长，并发写入没有一致性保证。ClickHouse解决的是"大批量数据算得慢"的问题，不是"所有数据库问题"。正确的做法是互补，不是替代。MySQL管交易，ClickHouse管分析。

```
MySQL（OLTP）          ClickHouse（OLAP）
  ↓                         ↑
  业务写入    → CDC同步 →    分析查询
  在线交易                   报表汇总
  高频更新                   批量分析
```

CDC是这套架构的关键。我用过两种方案：

**Canal + Kafka。** Canal伪装成MySQL从库，监听binlog，把变更事件发到Kafka，再由消费者写入ClickHouse。延迟通常在秒级。优点是不侵入业务代码，MySQL只要开了binlog就能用。缺点是多了一个Kafka组件，运维成本高一些。

**Flink CDC。** Flink直接读MySQL的binlog，做简单的ETL转换后写入ClickHouse。延迟也很低，而且Flink本身能做数据清洗和转换。缺点是需要额外部署Flink集群，学习曲线陡。

我个人偏好Canal方案，组件少，链路清晰。如果你的数据同步需求复杂（比如需要跨库聚合、格式转换），Flink CDC更灵活。

说了这么多ClickHouse，但列式存储不是它的专利。

越来越多的数据库在融合行存和列存。HTAP（混合事务/分析处理）架构试图用一个引擎同时做好OLTP和OLAP。TiDB的TiFlash是比较典型的例子——写入走TiKV（行存），通过Raft协议把数据实时同步到TiFlash（列存）副本，分析查询直接走列存。一份数据两个引擎，对业务层透明。OceanBase也在做类似的行列混存。

国产数据库在HTAP方向上也有探索。有的通过行列混存实现一份数据同时服务交易和分析，有的通过存算分离架构实现独立扩展。这条路还在走，现阶段的HTAP数据库在纯分析场景的性能和ClickHouse还有差距，纯交易场景的事务能力也不如传统行存数据库。但方向是对的——如果一个数据库能同时搞定交易和分析，运维复杂度确实能降不少。

现阶段，行列分离、各司其职仍然是最稳妥的方案。ClickHouse做分析，MySQL做交易，CDC做同步。等HTAP数据库成熟了，可以考虑替换。

## 避坑清单

1. **别上来就换数据库。** 先用EXPLAIN看执行计划，确认瓶颈真的是IO和扫描量，再考虑引入列存。很多时候加个索引、改个SQL就够了。
2. **ClickHouse的ORDER BY字段顺序要认真选。** 把最常用的查询过滤条件放第一位，不然稀疏索引形同虚设。我一开始随便排了个顺序，查询性能差了5倍，后来改成按实际查询模式排序才解决。
3. **CDC同步链路要监控。** Canal或Flink CDC偶尔会因为网络抖动或binlog格式问题丢数据。上线后一定要加监控，比如对比MySQL和ClickHouse的行数差异，发现不一致及时补数据。

## 总结

报表慢的根本原因可能不是SQL写错了，是存储引擎选错了。行式存储天生不适合大批量聚合分析，列式存储才是这个场景的正确工具。MySQL做OLTP没问题，加上ClickHouse做OLAP，用CDC做数据同步，这套架构我亲测有效。

但数据库选型不是选一个全能的，而是选对的组合。根据业务场景选最合适的引擎，比追求一个数据库解决所有问题更务实。

朋友，你的报表查询慢是怎么解决的？加了索引还是换了分析引擎？欢迎在评论区聊聊。

我是数据库小学妹，咱们下篇见 👋

上个月，一家零售企业的客户问我。他们的报表系统越跑越慢，按地区和月份汇总一次要八分多钟。

行式存储vs列式存储：MySQL与ClickHouse的性能对比与架构实践

MySQL跑报表越来越慢，加了索引也没用。我引入ClickHouse做分析，从列式存储原理到MergeTree引擎到向量化执行，对比了同一个查询在行存和列存上的性能差异，8分多钟的查询降到2秒。

数据库

架构设计

MySQL行式存储报表查询慢？列式存储ClickHouse让千万级数据聚合查询从8分钟降到2秒！揭秘列存压缩、向量化执行原理，对比MySQL与ClickHouse性能差异，分享OLTP+OLAP架构实战经验，解决大数据分析性能瓶颈。

数据清洗

数据同步

代码解释

Kafka

MySQL

OLAP

OLTP

2026上云采购 | AI焕新·智启新局

tchousec

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

行式存储vs列式存储：MySQL与ClickHouse的性能对比与架构实践-腾讯云开发者社区-腾讯云

行式存储vs列式存储：MySQL与ClickHouse的性能对比与架构实践

行式存储vs列式存储：MySQL与ClickHouse的性能对比与架构实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐