这些引擎的定位
ClickHouse 的表引擎家族里，Log 家族（TinyLog、Log、StripeLog）与 Memory 都属于「没有索引、不做合并」的简单引擎：数据按写入顺序存放，查询就是顺序读。它们的价值不在承载生产大表，而在承担小体积的辅助角色——维表、临时表、导入落地点与测试数据。
引擎对照
| 引擎 | 存储结构 | 适用与限制 |
|---|---|---|
| TinyLog | 每列一个文件，最简单 | 适合一次性小表；不保证并发读一致性 |
| Log | 每列文件加标记文件 | 支持并发读，适合中小型日志类表 |
| StripeLog | 所有列写在同一个文件 | 适合大量小表、每表列数少的场景 |
| Memory | 数据放在内存，重启即失 | 适合中间计算与测试；受内存上限约束 |
基本信息
| 适用平台 | ClickHouse（所有版本） |
|---|---|
| 索引能力 | 无主键索引，查询为顺序扫描 |
| 更新删除 | 不支持 ALTER DELETE / UPDATE 等 Mutation |
| 建表语法 | CREATE TABLE t (...) ENGINE = TinyLog |
| 常见搭档 | Buffer 表做写入缓冲、Join/Dictionary 引擎做小维表 |
典型使用场景
- 小维表与字典数据：几十万行以内、频繁被 JOIN 参照的场景
- 临时中间表：大查询分步落地，避免一次 SQL 写得太复杂
- 导入落地点：外部数据先落 TinyLog 再清洗写入 MergeTree
- 测试与演示：快速建表验证 SQL 逻辑，不关心持久化
- 一次性导出中间结果：跑完即删，不需要索引成本
建表与使用
建表与使用
-- 小维表：数据量小、只做顺序扫描，用 TinyLog 就够
CREATE TABLE tmp_items (id UInt64, name String) ENGINE = TinyLog;
-- 临时日志表：需要并发读时选 Log 而非 TinyLog
CREATE TABLE tmp_log (ts DateTime, level String, msg String) ENGINE = Log;
-- 内存表：只用于中间计算，重启后数据消失
CREATE TABLE mem_cache (k String, v String) ENGINE = Memory;
-- 从简单引擎把数据搬进正式表
INSERT INTO logs.events SELECT tenant, ts, service, ok, latency_ms FROM tmp_events;Log 家族不支持变更类操作（更新、删除）：一旦发现需要改历史数据，只能重建表并搬运数据，因此选型时就该判断这份数据是否会演化。
Memory 表的数据全在内存，且大结果集操作会额外占用内存：用它缓存大结果集很容易把服务器内存吃满，需要关注 max_memory_usage 与服务器总内存。