行式存储与列式存储：原理、差异与选型实战

做后端和数据基建这些年，存储格式的选择往往决定了系统的性能和成本边界。无论是选数据库还是设计数仓，行式存储（Row-based Storage）和列式存储（Column-based Storage）都是绕不开的基础概念。很多人对它们的认知停留在“OLTP用行存，OLAP用列存”这种口诀层面，但真到了排查慢查询、优化导入吞吐或者压榨存储成本的时候，光有口诀是不够的，得清楚底层到底发生了什么。这篇东西我尽量用大白话和实际场景，把这两种存储方式的原理、差异、适用场景和选型经验讲透。

1. 内容整体设计与思路拆解

1.1 为什么两种存储方式会并存

要理解这个问题，得先回到数据的本质。同一份数据，在磁盘上按什么顺序排列，直接决定了后续读数据的方式。

假设有一张订单表，包含订单编号、用户ID、商品ID、下单时间、支付金额、订单状态这几个字段。如果用行式存储写入，物理磁盘上是这样的逻辑排列：

text复制订单1: 10001, U1001, P5001, 2024-01-15 10:00:01, 299.00, 已支付
订单2: 10002, U1002, P5002, 2024-01-15 10:00:02, 59.90, 已支付
订单3: 10003, U1001, P5003, 2024-01-15 10:00:03, 129.00, 已取消

也就是说，一整条记录的所有字段被连续地放在一起。如果要查“用户U1001最近十笔订单”，只需要找到包含U1001记录的那些数据页，把整行数据读出来就能返回结果。

但如果是列式存储，同样是这三条记录，物理排列完全不同：

text复制订单编号: 10001, 10002, 10003
用户ID:   U1001, U1002, U1001
商品ID:   P5001, P5002, P5003
下单时间: 2024-01-15 10:00:01, 2024-01-15 10:00:02, 2024-01-15 10:00:03
支付金额: 299.00, 59.90, 129.00
订单状态: 已支付, 已支付, 已取消

所有订单编号放在一起，所有用户ID放在一起，所有金额放在一起。查询时如果只需要算“每天的支付总金额”，数据库可以直接跳过订单编号、用户ID、商品ID甚至订单状态这些列的数据块，只读取下单时间和支付金额两块区域。

这就是两种存储方式在物理层最本质的区别：数据组织的最小逻辑单元不同。一个以“整行”为组织单位，一个以“列”为组织单位。这个差异像多米诺骨牌一样，连锁决定了后面的压缩率、IO效率、索引适用性、事务处理模型，甚至决定了整个数据库的架构走向。

1.2 设计目标的差异决定了技术路线

在看存储引擎设计时，我习惯先问一个问题：这个系统的主要读者是谁？

传统OLTP系统的读者是用户和业务代码。比如你在电商App上打开订单列表，核心操作是：根据登录用户ID，找出他的订单，然后针对这几个订单做详情展示或状态更新。这种请求的特点是：

• 每次查询携带明确的条件，比如以某个ID为过滤条件；
• 返回的结果往往是“少数行的全部字段”；
• 要求极低的响应延迟和极高并发；
• 经常伴随写入和更新。

从面向“单行全字段”的访问模式来看，行式存储占绝对优势。记录被写在一起，读出来就是一条完整的记录，数据库可以一次性返回所有字段，通过主键索引快速定位到特定行所在的数据页，读取代价极小。传统数据库如MySQL的InnoDB、PostgreSQL默认堆表行存，本质上是围绕这种访问模式设计的。

OLAP系统的读者则完全不同。分析师和报表系统通常关心的是：

• 某个月各品类的销售总额是多少；
• 某时间段内每个用户的消费频次变化；
• 一万个商品的库存量排序。

典型的查询是“从海量行中提取少数列，做聚合运算”，比如 SELECT region, SUM(amount) FROM sales GROUP BY region。这时候影响性能的最大因素不再是行定位速度，而是“有多少数据需要从磁盘搬到内存”。如果用行式存储做这个查询，哪怕只需要两个字段，数据库也得把每一行完整的记录读进来，再解析字段做计算。假设一行有100个字段，但你只需要2个，那就等于98%的IO浪费掉了。列式存储可以从源头避免这种浪费——只读取涉及的那2列。

所以并不是谁比谁更好，而是两者的设计目标本身就不同。行式存储面向以行为中心的增删改查，列式存储面向以列为中心的批量分析。理解了这个根本点，后续各个细节的差异就都能理解透了。

1.3 列存不是“把行拆开”这么简单

一个常见的误解是把列式存储理解为“把行表的每个字段拆成单独的文件”。如果只是拆文件，你会立刻遇到一个尴尬的问题：数据一致性怎么办？

假设要更新一行里的一两个字段，在列式存储里，这些字段分布在不同的数据块中。要保证它们要么全部更新成功、要么全部失败，就需要跨多个文件的事务管理机制，代价非常大。如果处理不好，可能某次崩溃之后，订单金额被更新成了新值，但订单状态还停留在旧值。

所以现代列式存储方案绝不是简单的物理拆分。它需要另外考虑写入缓冲、不可变数据段、LSM树、稀疏索引等一系列机制。很多列式存储引擎，比如ClickHouse的MergeTree、Parquet文件格式，本质上都采用了“先写入行取向的缓冲，再批量转成列存块”的策略，目的就是兼顾写入实时性和分析性能。这也是为什么很多看似“列存”的系统，其实在写入链路里有一个行存CheckPoint。对这个点的理解，在后续做技术选型时极为关键。

2. 核心细节解析与实操要点

2.1 行式存储内部到底怎么组织数据

以最常用的InnoDB为例，表数据按主键顺序聚簇存放。每个数据页默认16KB，页内部存放着一行行完整记录，每个记录之间有指针相连。页与页之间通过B+树索引相连，主键索引的叶子节点直接包含完整的行数据。

这种结构带来的最直接收益是：

• 主键范围扫描很高效。因为数据本身按主键有序排列，查询 WHERE id BETWEEN 1000 AND 2000 时，可以顺序读取少量数据页，不需要大量跳跃式随机IO。
• 单行点查非常快。走主键索引后，可以直接算出数据在哪个页，然后一次IO拿到整行数据，返回所有字段的代价和返回1个字段的代价几乎一样。
• 行级别并发控制相对成熟。由于一整行在物理上相对集中，通过锁或MVCC实现冲突控制较为直观，这也是为什么OLTP数据库多采用B+树索引配合行级锁机制。

但要注意，行式存储在应对宽表分析查询时会有明显短板。比如表有80个字段，业务上每次只关心其中3个。因为存储以行为单位，这个查询仍然要把全部的80个字段从磁盘读入内存解析。如果表中有大字段，如一个用于存储商品图片URL的VARCHAR，或者JSONB格式的商品扩展属性，这些字段会让行变得更宽，数据页能容纳的行数变少，IO放大问题会进一步加剧。很多时候线上一个简单的分组统计慢查询，就是被这种IO放大效应拖垮的。

2.2 列式存储的底层结构优势

列式存储的底层优势不止“减少IO读取量”一个。把它拆开看，主要有四层逻辑：

第一，天然的高压缩率。同一列的数据类型一致，数值范围和分布往往接近，这意味着可以用更激进的压缩算法。比如支付金额这一列，可能在0元到1000元之间分布，使用delta encoding或字典编码，压缩率能做到5到10倍甚至更高。而如果是一整行混着字符串、数字、时间戳，压缩算法很难在“一行”的有限数据里找到足够多的重复模式，压缩率自然上不去。压缩不仅仅是省空间，更重要的是减少磁盘到内存的数据读取量。假设数据压缩了4倍，那么同样大小的IO吞吐下，实际能加载进内存的有效数据量翻了4倍。

第二，延迟物化（Late Materialization）效果。因为列数据各自独立，数据库可以在过滤阶段只读取少量列，通过行号定位或位图标记过滤条件命中的行，最后才把需要的列组装成最终结果。这样中间过程产生的数据量比提前组装整行小很多，减轻计算和内存压力。

第三，更适合现代CPU的向量化执行。列存中同一列的值连续排布，格式统一，很容易加载成SIMD指令能够处理的数组。很多分析引擎如DuckDB、ClickHouse对列存数据做批量计算时，直接一次处理一批数值，而不是逐行解析，计算吞吐量有数量级差异。

第四，稀疏索引和Zone Map可以减少无关数据读取。列存引擎通常会在数据块上记录每列的最小值、最大值、数据块行数范围、空值数量等元数据。执行查询时先做元数据过滤，如果筛选条件的下界高于某块最大值，或者上界低于某块最小值，整个数据块可以直接跳过，连“读取”都不用发生。比如查询“找出金额大于10000的记录”，如果某个块记录的最大金额只有8000，那这一整块数据直接跳过。

2.3 行转列后查询性能差异有多大

为了有个直观概念，可以看一个实际例子。假设有一张销售明细表，存储了1000万条销售记录，每条记录包含订单ID、商品类目、销售区域、销售额、成本、销售时间、渠道等20个字段。平均每行约200字节，数据总量约2GB。

现在跑这样一条查询：

sql复制SELECT SUM(sales_amount) 
FROM sales 
WHERE sale_date >= '2024-01-01' AND sale_date <= '2024-03-31' 
  AND region = 'east';

假设第一季度符合条件的记录有300万行。在行式存储下，即便有sale_date和region的二级索引，最常用的执行计划也是索引找出满足条件的记录ID，然后回表读完整行。每次IO读出的数据页包含完整行，20个字段里实际有用到的字段只有sale_date、region、sales_amount，占比不到三成。那么粗略估算，为了统计销售额，磁盘至少要读取200字节乘以300万行，也就是600MB以上的原始数据。而在合理压缩的列式存储中，只需读取两个过滤列（时间和区域）和一个统计列（金额），三个列的压缩后数据量加一起通常不会超过30MB。在同样的磁盘吞吐能力下，二者可能是数十倍的查询延迟差异。

这个例子不是为了论证“列存绝对好”，而是要说明一个核心原则：分析型查询的开销与“实际读取的数据量”正相关，列存从物理上大幅缩小了这个量。

2.4 列式存储的先天短板

没有哪种方案只有优点。列式存储的短板同样明显，很多情况下甚至是致命缺陷。

最显著的问题是对单行操作的代价极高。要更新一条完整记录，如果按逻辑做法，需要分别定位并重写多个列压缩块。实际上很多列存引擎做更新时会把更新记录先写入一个delta缓冲区域，后台再与主数据块合并。这种方案适合批量更新场景，但如果业务是高并发地“把订单A的状态改成已发货，同时把金额改成250元”，那延迟和冲突开销就会显著放大，远不如行存中就地更新一行来得自然。

其次是事务支持和跨列一致性变复杂。列的物理分布非常分散，行存事务在同一个页内完成多个字段的原子修改，而列存如果一行修改涉及5列，等于要原子性地操作5个不同文件偏移位置。这对底层实现的要求很高，也是HBase这类介于两者之间的系统采用“用行键聚合相关列族”的逻辑来扬长避短的原因。

再次，如果查询需要“一批行的所有字段”，比如业务上要求把10000条订单记录完整打印出来，列存反而可能因为需要拼装多个列块而比行存更慢。列式存储擅长的是列裁剪后的分析，不是全行大范围导出。

3. 实操过程与核心环节实现

3.1 手工模拟两种存储的数据分布

理解物理存储最直接的方法是自己动手模拟一次。不需要启动任何数据库，只需要几行Python脚本，把同一批数据分别用“行式”和“列式”方式写入文件，再统计不同查询模式下读取的数据量。这个实验能帮助建立直观物理记忆。

假设有10万条数据，每条记录4个字段：

python复制# data_list 结构为 [(id, category, amount, timestamp), ...]
# 行式写入
with open('row_storage.bin', 'wb') as f:
    for record in data_list:
        for field in record:
            f.write(str(field).encode() + b'|')
        f.write(b'\n')

# 列式写入
cols = list(zip(*data_list))
with open('col_storage.bin', 'wb') as f:
    for col in cols:
        for val in col:
            f.write(str(val).encode() + b'|')
        f.write(b'\n')

如果查询目标是“计算类别为A的总金额”，行式存储需要逐行把4个字段都读进来再做判断；列式存储则只需要读取第一列的category数据和第三列的amount数据，少读一半或更多数据。虽然是模拟，但和真实数据库的原理完全一致。

3.2 在单机环境下实测行存列存不同访问模式性能

假设环境里同时有PostgreSQL和ClickHouse，可以分别建表做对比实验。这比空谈理论更容易形成记忆。

先在PostgreSQL建一张订单表：

sql复制CREATE TABLE orders (
    order_id BIGINT PRIMARY KEY,
    user_id BIGINT,
    product_id BIGINT,
    amount DECIMAL(12, 2),
    status VARCHAR(20),
    created_at TIMESTAMP
);

插入100万行随机数据，然后执行下面的分析查询：

sql复制SELECT status, COUNT(*), SUM(amount) 
FROM orders 
WHERE created_at >= '2024-01-01' 
GROUP BY status;

用EXPLAIN ANALYZE看耗时。在行存表上这个查询的规划通常会选择全表扫描，因为created_at字段上没有统计信息足够优化的索引，且返回的行数可能很大。全表扫描意味着每一行每一列都被读入内存。

同样的数据导入ClickHouse，用MergeTree引擎按created_at排序。执行同样的查询，但SQL改成ClickHouse风格：

sql复制SELECT status, count(), sum(amount) 
FROM orders 
WHERE created_at >= '2024-01-01' 
GROUP BY status;

在有主键排序的MergeTree中，如果数据是按created_at物理排布的，分区和索引会直接跳过很多不必要的part；即使没有一级索引过滤，列式读取也只需要扫描created_at、status、amount三个列，整体IO与行存不在一个量级。

实测结果通常是ClickHouse的查询耗时比PostgreSQL少一个或两个数量级，前提是数据量大到能掩盖启动开销和引擎差异。对于小数据集，比如几千行，两者差异往往感受不明显，甚至行存更快——因为启动开销和查询解析占了大头。这也是很多新手在测试环境里感受不到列存优势的原因之一。做这类实验，建议数据量至少到百万级。

3.3 应对“既要又要”的存储需求怎么办

实际业务中很少有百分之百的纯OLTP或纯OLAP。电商平台既要支持订单详情秒级查询，又要跑运营数据分析报表。这种场景最常用的方案是“HTAP”或者“Lambda架构”，本质思路都是保留一份行存主库，再把数据同步到列存引擎中做分析。

一个比较经典的落地方案：

• 主库用MySQL或者PostgreSQL，承担所有实时的订单写入、状态更新、详情查询；
• 通过Debezium订阅MySQL的binlog，或者用PostgreSQL的逻辑复制，实时把数据变更投递到Kafka；
• 下游使用ClickHouse或Doris从Kafka消费数据，写入MergeTree或Unique模型作为列存分析副本；
• 业务分析平台统一查询分析副本，分析查询绝不直接打到OLTP主库。

这套架构要踩的坑也不少。最常见的就是数据同步延迟问题：如果同步链路出现阻塞，列存副本的数据落后，报表结果可能误差比较大。所以链路里必须有延迟监控和告警，同时配置数据核对任务做定期checkpoint。

另一个容易被忽视的细节是数据模型设计。MySQL里的字段类型到列存引擎不一定好用，比如字符串类型在ClickHouse做GROUP BY时可能比数值类型开销大得多；又比如同一个查询在MySQL里可以利用复合索引避免排序，但在ClickHouse里可能需要显式optimize或把排序列作为ORDER BY键。同步时如果只做字段映射，不做类型和排序键的适配，分析性能会打折扣。

3.4 主流存储引擎分类与选型速查

互联网上关于“哪个数据库好”的争论从未停息，实际上脱离访问模式谈数据库优劣没有意义。整理一份速查表，按存储模型分类标注常见引擎和适用场景，方便对照业务需求做初筛：

一张速查表不能替代测试，但能帮你在项目初期少走很多弯路。从经验看，在数据量小于千万的时候，纯行存照样能把分析跑得不错；真正需要列存的拐点往往是数据量过了亿、或者列数增加导致IO放大明显之后。所以不要过早精细化，先能用、再优化，同样适用在存储选型上。

4. 常见问题与排查技巧实录

4.1 为什么列存引擎做点查反而慢

之前见过一个用户行为分析系统，把用户明细数据全部存进ClickHouse，然后每天要看“用户A今天的最后一条行为”。SQL写的是：

sql复制SELECT * 
FROM user_events 
WHERE user_id = 'u123456' 
ORDER BY event_time DESC 
LIMIT 1;

这个查询在MySQL里也许几毫秒就返回了，但在ClickHouse中经常要一两秒。原因在于列式存储的稀疏索引只定位到行组级别，不能像B+树那样精确定位到某一行的物理位置。即使通过二级索引或主键索引找到了包含目标user_id的part，内部仍可能需要扫描整个granule的数据块，再过滤出目标记录。除非查询条件本身很少做，否则这种点查在列存里可能反而吃亏。

如果业务场景必须支持高频点查加低频分析，不要强行把一个OLTP负载变成一个OLAP查询。更务实的方案是保留行存主库，或者使用那些为点查做了优化的列存变体，比如对行键进行特殊建模的存储系统。

4.2 行存加索引为什么也Cover不住大宽表分析

这个问题经常出现在业务扩张期。一张订单表因为各项扩展越加越宽，达到了几十个字段，然后统计分析SQL开始频繁触发慢查询，加个联合索引效果不明显。原因在于联合索引本质上只是让“过滤阶段”更快，真正参与聚合的列仍然要回表读取。比如统计“每小时的销售额”，即便索引能够快速筛选时间段，sum(amount)还是要读取大量行记录。行宽越大，回表IO放大越明显。

遇到这种情况，不要继续在行存上面堆索引，可以先从查询模式判断：如果这个查询是固定几个列的大范围汇总，应该考虑引入列存副本，由离线分析引擎承载。线上主库只保留与OLTP强相关且访问频繁的字段，其他扩展字段挪到宽表存储或列存表，减少因为行宽导致的基础IO浪费。

4.3 压缩之后数据量为什么没有想象中小

列存并不等于压缩率高，压缩率取决于数据的真实分布和编码方案。两个主要影响因素是基数（Cardinality）和数据排列的有序性。

如果一列是唯一值比例极高的ID列，每个ID基本不同，字典压缩几乎无效，甚至可能比原始数据更大（因为存储字典本身也需要开销）。如果一列是状态字段，只有几个固定枚举值（如待支付、已支付、已取消），字典编码后数据量可以缩小到原来的几十分之一。

另一个重要因素是排序列的选择。很多列存引擎的压缩算法会对相邻数据做增量差分或前缀压缩，如果排序列保证相同取值尽量聚集，后续其他列也能共享这个排序，从而让同值区域更连续，压缩效果更好。这也是为什么在ClickHouse建表时，ORDER BY键不能只从“查询过滤最频繁”的角度选，还要考虑与常见GROUP BY、范围查询条件的契合度。直接按时间戳排序是最常见的入门操作，但要根据业务场景做取舍，不能一刀切。

4.4 主键排序键频繁用错导致数据倾斜

列存表如果排序键选得不好，最典型的问题是数据倾斜和读取放大。把业务类型字段直接作为排序键首位，如果业务类型特别集中，比如订单状态绝大多数是“已完成”，还会导致底层数据块在“已完成”的区域扎堆，虽然压缩率高，但在按业务类型做高频过滤时反而容易命中到某一个巨大区域的数据块，降低并行度。

解决办法是排序键可以使用高阶组合字段，让高基数列优先，再配合低基数列做二级排序。同时如果不希望只依赖单一排序顺序，可以考虑在多副本表上使用不同的ORDER BY键来适配不同查询负载，但这属于较高阶的调优，初学阶段先把排序键和查询模式对齐，已经能解决大部分性能问题。

4.5 查坏列时案例：Row Order与Column Order混淆导致的问题

有一次排查一个外部分析平台的性能问题，发现在该平台上导出的同一表数据，用Parquet格式竟然比CSV格式还要慢。这个反直觉现象让人困惑了很久。

后来检查发现导出工具没有做合适的行组统计，也没有启用谓词下推和列裁剪，Parquet实际上把整表全列都物化了。数据源端根本没按分析负载来推过滤条件，Parquet的优势没有得到发挥，反而因为文件格式的元数据开销让读取变慢。这个案例给人的教训是：数据格式的优势必须由查询引擎的执行计划配合触发，不能指望到了格式层面“自动生效”。加载数据到数仓时，至少要让引擎知道外部表每个文件的schema和统计信息，并确认谓词下推是打开的。

5. 实操心得与常见误区补充分享

5.1 列存并不等于“分析一定能快”

经常有人看到业务系统查询慢，就兴致勃勃地想把所有表改成列存。有一次在技术群里看到一位同学把订单表从A库迁移到ClickHouse，结果发现按用户ID查询历史订单的接口延迟从50ms上升到800ms，页面直接超时。原因前面已经有提到：列存完全不擅长单行查询场景。

所以，列存的快有一个前提——大范围扫描、少列读取、批量预聚合、数据过滤后参与计算的行数占比高。如果查询本质上是返回少数行的全字段数据，列存只会放大问题。

5.2 数据湖上的列存文件也需要维护

不只是数据库，数据湖场景下Parquet和ORC这些列存格式同样需要定期维护。很多离线数仓的使用者总是盯着Spark或引擎配置，忽略文件本身的元数据统计过期问题。定期执行ANALYZE TABLE刷新统计信息，或者按分区重写小文件合并成大文件，效果往往立竿见影。特别是在按时间增量写入数据的场景里，小文件碎成几十万份时，行组统计严重碎片化，再好的列存格式也救不回来。

5.3 不要忽视“数据读取量”这个概念

不同存储方案的性能差异，从底层逻辑来看最终还是落在这几个指标上：

• 查询从磁盘读取的有效数据量；
• 数据经过压缩后在IO层实际传输的大小；
• 从磁盘到内存再到CPU的计算链路上，有多大比例是“有效数据”。

行式存储的优势是单行修读低延迟，列式存储的优势是大批量列扫描低IO消耗。建立底层物理数据组织的直观印象后，看执行计划、设计表结构、选技术栈都会更从容。把这句话刻在脑子里，遇到问题逐层排查，基本不会偏离正确方向。

5.4 千万别迷信“默认配置”

不少数据库在“一致性”“性能”“压缩率”上提供了很多可调参数，但默认配置往往根据最常见场景设定。行存和列存之间并不是一条不可逾越的鸿沟。如果你真的遇到“既要事务型的行访问，又要分析型扫列”的复杂业务，不要急着在现有系统上硬凑，可以考虑引入专门的列存副本或使用混合存储引擎，让合适的存储做合适的事。这种投入换来的是后续系统多年稳定与可维护性，这个账不难算。

以我个人的实际体会来说，行式存储与列式存储的选择，本质上是围绕“数据如何被消费”做权衡，而不是凭性能数据选型。先把业务的读写模型搞清楚，再去匹配存储引擎，比什么都重要。很多维护期的痛苦，其实都是前期选型时欠下的技术债。搞清楚行存与列存的不同物理逻辑，会给后续数据库调优、数仓建模和查询优化省下大把时间。