TL;DR

• 场景：需要在小数据/临时表/日志落地/多表拼读里做权衡，常被 MergeTree “杀鸡用牛刀”。

• 结论：用这套选型表 + MRE + 并发/文件核验脚本，10 分钟跑通 5 个引擎的核心差异。

• 产出：引擎的测试所有详细过程，附带 SQL 等内容

版本矩阵

90 秒原理

• TinyLog：每列各一个 .bin 压缩文件，追加写；基本不处理并发，写期间读会受限。

• Log：在列旁存标记（offset），支持多线程读取；同表写入阻塞其他写/读。

• StripeLog：把所有列写到一个 data.bin，标记集中化，FD 占用更少、读并行稳定。

• Memory：纯内存存储，重启丢失；适合小体量/测试/高速算子。

• Merge：只读“聚合视图”，不存数据；查询下沉到底层表的引擎执行。

选型决策

简单介绍

表引擎（即表的类型）是数据库系统中决定数据管理和处理方式的核心组件。它将直接影响数据库的性能、功能特性和适用场景。具体来说，表引擎决定了以下几个关键方面：

1. 数据的存储机制：

2. 物理存储格式：包括行存储（如 InnoDB）、列存储（如 ClickHouse 的 MergeTree）或内存存储（如 Memory 引擎）

3. 存储位置：可以存储在磁盘、SSD、内存或分布式文件系统中

4. 读写路径：例如有些引擎会先将数据写入内存缓冲区再持久化到磁盘

5. 查询支持能力：

6. 支持的查询类型：如全文检索、聚合查询、时序数据处理等

7. 查询优化方式：不同的引擎会采用不同的查询执行计划

8. 特殊功能支持：例如地理空间数据处理、JSON 文档处理等

9. 并发控制：

10. 锁机制：行级锁、表锁或乐观并发控制

11. 事务隔离级别：如读已提交、可重复读等

12. MVCC（多版本并发控制）实现方式

13. 索引策略：

14. 索引类型：B 树、LSM 树、倒排索引等

15. 索引维护方式：有些引擎支持自动维护，有些需要手动维护

16. 索引选择性：不同引擎对索引的使用效率可能有显著差异

17. 并行处理能力：

18. 多线程查询执行：某些引擎可以将单个查询分解为多个并行任务

19. 分布式查询处理：在集群环境下跨节点并行执行查询

20. 资源隔离：控制并发查询对系统资源的占用

21. 数据高可用性：

22. 复制机制：如主从复制、多主复制等

23. 故障恢复：自动故障转移和恢复能力

24. 数据一致性保证：强一致、最终一致等不同级别

25. 特殊功能：

26. 数据 TTL（生存时间）

27. 数据压缩算法

28. 加密存储支持

29. 物化视图支持

实际应用中，选择表引擎需要综合考虑业务需求（如是否需要事务支持）、数据特征（如数据量大小、访问模式）和系统环境（如单机还是分布式）。例如，在 ClickHouse 中，MergeTree 系列引擎适合分析场景，而 Log 引擎则适合临时数据；在 MySQL 中，InnoDB 适合事务处理，MyISAM 则适合读密集型应用。

ClickHouse 是一个列式数据库管理系统，支持多种表引擎，每种表引擎都有其特定的功能和用途。以下是一些常用的 ClickHouse 表引擎：

MergeTree 系列

• MergeTree：最常用的表引擎，支持高效的分区、排序、索引等功能，适合处理大量写入和查询场景。支持主键和索引。

• ReplicatedMergeTree：基于 MergeTree，但增加了复制功能，适用于分布式集群环境。

• ReplacingMergeTree：允许以最新的记录覆盖旧的记录，对于需要根据特定列去重的场景非常适用。

• SummingMergeTree：支持对数值列的聚合，适用于需要进行聚合计算的场景。

• AggregatingMergeTree：支持更加复杂的聚合操作，适合需要预计算汇总的场景。

• CollapsingMergeTree：用于处理日志式数据，通过将 "begin" 和 "end" 记录合并，以减少存储空间。

• VersionedCollapsingMergeTree：在 CollapsingMergeTree 基础上，增加了版本号，用于更好地控制数据合并。

Log 系列

• Log：简单的表引擎，不支持索引和分区，适合小数据量或日志式的存储场景。

• TinyLog：适合嵌入式场景或测试，性能更简单，不能处理大规模数据。

• StripeLog：适合 SSD 场景，按行写入，但会将数据按块组织，适合某些特定读写模式。

• Memory：数据只存储在内存中，适用于需要快速读写但不需要持久化的场景。

• Distributed：在分布式集群中使用，将查询分发到多个节点，适合大规模数据和高并发查询场景。

• Merge：将多个表作为一个虚拟表进行查询，适合需要联合多个表进行读取的场景。

• Join：预加载并存储 Join 表，用于提高连接操作的效率。

View 系列

• MaterializedView：物化视图，允许通过预计算来加速查询。

• View：普通视图，不会存储数据，只是查询的定义。

• Buffer：将数据暂时存储在内存中，并定期批量写入到基础表中，适合需要优化写入性能的场景。

• Null：将数据写入时直接丢弃，适合测试场景。

日志

TinyLog

最简单的表引擎详解

存储结构与机制

这种表引擎采用最基本的列式存储方式，每列数据单独存储为一个压缩文件（如.bin文件），使用轻量级压缩算法（如 LZ4 或 ZSTD）来减少磁盘空间占用。写入操作采用追加(append-only)模式，所有新数据都会被添加到对应列文件的末尾，而不会修改已有数据。

并发限制说明

1. 读取并发：

2. 当有写入操作正在进行时，任何并发的读取操作都会立即抛出"Table is locked for writing"异常

3. 示例场景：如果后台任务正在导入数据，此时用户查询会直接失败

4. 写入并发：

5. 多个写入操作同时执行会导致数据文件损坏

6. 典型问题表现：列数据不完整、行计数不一致、数据乱码等

适用场景分析

1. 最佳使用模式：

2. 一次性写入(Write-Once-Read-Many)

3. 适合配置表、维度表等不常变更的数据

4. 典型应用：存储产品分类、地区编码等基础数据

5. 容量建议：

6. 官方建议上限：1,000,000 行

7. 实测性能拐点：约 50-100MB 单表数据量

8. 小表优势：单个查询通常只需打开 2-3 个列文件

9. 特殊场景优势：

10. 小表集群(1,000+个小表)场景下表现优异

11. 相比其他引擎可减少 50%以上的文件描述符占用

12. 冷数据归档存储的理想选择

功能限制

1. 索引支持：

2. 完全不支持任何类型的索引

3. 所有查询都是全表扫描

4. 解决方法：对高频查询字段考虑物化视图

5. 性能特征：

6. 写入速度：约 10-50MB/s（取决于硬件）

7. 读取延迟：与数据量线性相关

8. 内存占用：仅需最基本的缓冲区（通常<10MB）

9. 维护注意事项：

10. 不支持 ALTER TABLE 修改表结构

11. 数据删除需通过重建表实现

12. 没有自动的压缩整理机制

测试 1

创建一个 TinyLog 引擎的表并插入一条数据

CREATE table t (a UInt16, b String) ENGINE = TinyLog;INSERT INTO t (a, b) VALUES (1, 'abc');

运行结果如下所示：

此时我们去保存数据的目录下查看:

cd /var/lib/clickhouse/data/default/tls

运行结果如下图：

文件列表的解释：

• a.bin 和 b.bin 是压缩过的对应列的数据

• sizes.json 中记录了 每个 bin 的大小

Log

Log 与 TinyLog 不同的是，标记的小文件与列文件存在一起，这些标记写在每个数据块上，并且包含偏移量，这些偏移量指示从哪里开始读取文件以便跳过指定的行数。这使得可以在多个线程中读取表数据，对于并发数据访问，可以同时执行读取操作，而写入操作则阻塞读取和其他写入。Log 引擎不支持索引。同样，如果写入表事变，则该表会被破坏，并且从该表中读取将会返回错误。Log 引擎适合于临时数据，write-once 表以及测试或演示目的。

StripeLog

该引擎属于日志引擎系列，在你需要写入许多小数据量（小于 100 百万行）的表的场景下使用这个引擎。

写数据

StripeLog 引擎将所有的列存储在一个文件中，对每一个 INSERT 请求，ClickHouse 将数据块追加在表文件的末尾，逐列写入。ClickHouse 为每张表写入如下文件：

• data.bin 数据文件

• index.mrk 标记文件，标记包含了已插入的每个数据块中每列的偏移量。

StripeLog 引擎不支持 ALTER、UPDATE、ALTER DELETE 操作。

读数据

带标记文件使得 ClickHouse 可以并行的读取数据，这意味着 SELECT 请求返回行的顺序是不可预测的，使用 ORDER BY 子句对行进行排练。

新增表

CREATE TABLE stripe_log_table (  timestamp DateTime,  message_type String,  message String) ENGINE = StripeLog;

执行结果如下图所示：

插入数据

INSERT INTO stripe_log_table VALUES (now(), 'REGULAR', 'The first reqular message');INSERT INTO stripe_log_table VALUES (now(), 'REGULAR', 'The second regular message'),(now(), 'WARNING', 'The first warning message');

我们使用两次 INSERT 请求从而在 data.bin 文件中创建两个数据块。

查询数据

ClickHouse 在查询数据时使用多线程，每个线程读取单独的数据并在完成后独立的返回结果行，这样的结果是，大多数情况下，输出中的块的顺序和输入时相应块的顺序是不同的，例如：

SELECT * FROM stripe_log_table;# 对结果排序（默认增序）SELECT * FROM stripe_log_table ORDER BY timestamp;

执行的结果如下图：

Memory

内存引擎，数据以未压缩的原始形式直接保存在内存中，服务器重启数据就会丢失。读写操作不会互相阻塞，不支持索引。简单查询下有非常高的性能表现：超过 10G/s 一般用到的地方不多，除了用来测试，就是需要非常高的性能，但是数据量又不能太大（上限大概 1 亿行）的场景。

Merge

Merge 引擎（不要与 MergeTree 搞混）本身不存储数据，但可以用于同时从任意多个其他的表中读取数据，读是自动并行的，不支持写入。读取时，那些被真正读取到数据的表的引擎（如果有的话）会被使用。

Merge 参数：

• 数据库名

• 匹配表名的正则表达式

创建新标

CREATE table t1 (id UInt16, name String) ENGINE = TinyLog;CREATE table t2 (id UInt16, name String) ENGINE = TinyLog;CREATE table t3 (id UInt16, name String) ENGINE = TinyLog;

执行结果如下图所示：

插入数据

INSERT INTO t1 (id, name) VALUES (1, 'first');INSERT INTO t2 (id, name) VALUES (2, 'second');INSERT INTO t3 (id, name) VALUES (3, 'i am in t3');

执行结果如下图：

建立链接

CREATE TABLE t (id UInt16, name String) ENGINE = Merge(currentDatabase(), '^t');

执行结果如下图所示：

常见问题

其他系列

🚀 AI 篇持续更新中（长期更新）

AI 炼丹日志-29 - 字节跳动 DeerFlow 深度研究框斜体样式架 私有部署 测试上手 架构研究，持续打造实用 AI 工具指南！AI-调查研究-108-具身智能 机器人模型训练全流程详解：从预训练到强化学习与人类反馈🔗 AI模块直达链接

💻 Java 篇持续更新中（长期更新）

Java-154 深入浅出 MongoDB 用 Java 访问 MongoDB 数据库 从环境搭建到 CRUD 完整示例 MyBatis 已完结，Spring 已完结，Nginx 已完结，Tomcat 已完结，分布式服务正在更新！深入浅出助你打牢基础！🔗 Java模块直达链接

📊 大数据板块已完成多项干货更新（300 篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解🔗 大数据模块直达链接