行存储 vs 列存储：把数据摆成两排，结果天差地别

想象你走进一家图书馆。

行存储的做法是：把同一本书的每一页按顺序钉在一起，整本书整整齐齐塞进书架。

列存储的做法是：把所有书的第一页抽出来放一起，第二页放一起，第三页放一起……像扑克牌洗牌一样重新码放。

两种摆法听起来只是“顺序”不同，却决定了数据库的“性格”。

行存储：像传统图书馆，找书快，翻页也快

PostgreSQL、MySQL 等日常事务型数据库（OLTP）都选这种摆法。

原因很简单——一条记录的所有字段在磁盘上挨在一起。

当你只想查一台相机的完整信息：

SELECT * FROM camera WHERE model = 'A7R';

数据库只需一次定位，把整条记录的所有字段一次性拖出来，省时省力。

这种场景的特点是：

o 每次只查少量记录（甚至就一条）。

o 但要把这条记录的所有字段都带回去。

列存储：像把书拆了，按页归档，做统计飞快

Google BigQuery、ClickHouse 这类分析型数据库（OLAP）则反其道而行：

把同一列的全部值压成一条长龙，所有列各自成军。

这样做有两个立竿见影的好处：

1. 压缩率更高。

如果“品牌”这一列里 90% 都是 “Sony”，压缩算法能把重复值压到极限。

2. 只扫需要的列。

当你想算个平均价：

SELECT AVG(price) FROM camera;

行存储必须逐行把每条记录的所有字段读出来，再挑出 price；

列存储直接只读 price 那一列，磁盘 I/O 瞬间降到原先的零头。

什么时候混着用，什么时候分家？

o 数据量小时，公司往往“一书多用”：让主库（行存储）既跑交易又跑报表，最多把报表甩给只读副本。

o 数据量大后，报表查询会把主库拖垮。于是大家开始“分工”：

o 交易数据继续待在 PostgreSQL / MySQL；

o 分析报表交给专门的列存储，甚至再加一层数据仓库或 BI 工具。

一句话总结

别把螺丝刀当锤子，也别拿锤子拧螺丝。

选数据库也一样——用对工具，活干得漂亮，人也轻松。