clickhouse支持行存吗？什么时候开始支持的

简短结论先行：

ClickHouse 本质上是列式存储（column-oriented），并不支持真正意义上的"行存（row-store）"。

但从 2021～2022 年（约 21.x / 22.x 版本）开始 ，ClickHouse 逐步引入了"面向行的写入 / 读取优化能力" ，用来改善点查、小批量写、OLTP 类场景的性能------这是"行友好"，但不是"行存引擎"。

下面把这个问题彻底讲清楚，避免概念混淆。

---

一、ClickHouse 是否支持"真正的行存"？

❌ 不支持（截至目前）

ClickHouse 没有像 MySQL / PostgreSQL 那样的：

• 行式存储引擎
• 行级 B-Tree / Heap
• 一行一行落盘的物理布局

ClickHouse 的底层存储结构始终是：

按列分文件（Column Files）
→ 按块（Block / Granule）组织
→ 向量化执行

也就是说：

磁盘布局始终是列存，而不是行存

---

二、那为什么很多人说「ClickHouse 开始支持行存了」？

这是一个常见但不严谨的说法，真实情况是👇

ClickHouse 支持的是：

Row-oriented Access / Write Optimization（行友好能力）

而不是 Row Store。

---

三、ClickHouse"行友好能力"的时间线

1️⃣ 早期（≤ 20.x）

• 强列存

• 不适合：

  • 点查
  • 单行写
  • 高频小批量 insert

• 强依赖大批量 append

---

2️⃣ 21.x ～ 22.x（关键阶段）✅

从 2021 年左右开始，ClickHouse 引入并完善了：

✅ 行式写入优化

• Values / RowBinary / JSONEachRow
• 小批量 insert 性能提升
• 减少频繁 part 生成

✅ 行式读取优化

• Late materialization（延迟物化）
• Primary Key 点查优化
• SELECT ... WHERE pk = xxx LIMIT 1 成本下降

✅ Compact Parts

• 小 part 合并
• 改善近似 OLTP 写入

👉 这些让 ClickHouse "看起来"能做行级访问

---

3️⃣ 23.x ～ 24.x（成熟阶段）

• 对：

  • 点查
  • 窄列查询
  • 高频 insert

• 体验明显改善

• 但底层仍然是列式 + 向量执行

---

四、几个关键概念，必须分清

1️⃣ Row Store（行存）

特征	是否支持
一行连续存储	❌
行级索引	❌
行级更新	❌
OLTP 事务	❌

👉 ClickHouse 不支持

---

2️⃣ Row-oriented Access（行友好访问）

能力	ClickHouse
点查一行	✅（有限）
小批量 insert	✅
窄列查询	✅
向量化执行	✅

👉 这是 ClickHouse 的方向

---

五、为什么 ClickHouse 不做真正的行存？

这是一个架构选择问题：

1. ClickHouse 的核心目标：

   • OLAP
   • 扫描
   • 聚合
   • 吞吐

2. 行存会破坏：

   • 压缩率
   • 顺序 IO
   • 向量化

3. 如果要行存：

   • 直接用 MySQL / TiDB / PostgreSQL 更合理

👉 ClickHouse 选择的是：

"尽量把列存在点查场景下做到不那么慢"

---

六、什么时候"可以把 ClickHouse 当半个行存用"

⚠️ 只能在非常有限的前提下：

• 明确主键（ORDER BY）
• 点查 / 小范围查询
• 不涉及更新
• 写入仍然 append-only

例如：

SELECT *
FROM t
WHERE user_id = 'u123'
LIMIT 1;

✔ 可接受

❌ 不能当 MySQL 替代

---

七、一句话总结（记住这个）

ClickHouse 从 21.x 开始增强了"行友好能力"，
但它从来、也目前仍然不支持真正的行存。