第3章 存储引擎：列存、压缩与持久化

第3章 存储引擎：列存、压缩与持久化

本章要回答的三个问题：同样一份数据，按列摆放为什么就能让查询快好几倍？压缩不是为了让文件更小吗，为什么它还能让查询更快？每天要分析的文件，到底该放 DuckDB 自有格式、转成 Parquet，还是每次直接读 CSV？

为什么会有这一章

第2章解决了"引擎转得动"的问题，本章解决"数据摆得好不好"。这两件事共同决定查询速度，但后者常被忽视：同一台机器、同一条 SQL，仅仅因为数据躺在 CSV 而不是列式文件里，耗时就能差出十倍。更隐蔽的是持久化层面：预写日志和检查点的机制决定了"断电后数据还在不在"以及"库文件为什么会悄悄变大"。不理解这些，你就只能对着文件体积和查询耗时发呆。

本章的知识地图是一条数据的一生：进来时是什么格式（直查与集成），摆成什么物理结构（行组与列段），用什么算法压起来（编码），怎么安全地写下去（日志与检查点）。四节正好四站。四站的顺序也决定了学习收益的先后：3.1 与 3.2 直接解释"为什么列式快"，是理解本引擎的钥匙；3.4 是马上能用的工作技巧；3.3 平时隐身、出事时救命——按这个顺序读，每一节都为下一节备好了概念。

读完能解决什么

读完本章，你应当能做四件事。第一，画出列存文件的物理布局草图——行组、列段、统计信息各自在哪，并解释一次扫描是怎么靠布局跳过无关数据的。第二，看懂常见压缩编码的适用条件，能对着自己的列类型猜个八九不离十，并且明白"压缩数据直接参与计算"为什么成立。第三，说清预写日志与检查点的配合关系，能回答"导入到一半断电会怎样""库文件为什么比数据本身还大"这类实操问题。第四，掌握 CSV、Parquet、DuckDB 自有格式三者的取舍矩阵，为不同频次的文件选对栖身之所——主线案例的全量数据就将在本章完成第一次"搬家"。衡量标准照旧是动手型的：读完最后一节，你应该能对新到手的一份文件，在十分钟内给出"放哪、怎么放、为什么"的三连答案。

本章存储全景

图上有两条流：读路径从上到下——外部文件、行组、列段、编码块，层层往下取数；写路径在右侧——写事务先进日志，检查点时才合并进正式文件。两条流在"行组与列段"处汇合，那里是存储引擎的心脏，也是第3.1节的主题。读图时还可以带一个商业比喻：读路径像零售——按需求小批量取货，越精准越省钱；写路径像批发——攒够一批、一次性入账，越成批越高效。四节内容就是把这两条流水线的每个环节各开一讲，读完你会发现自己看数据文件的眼神从此不同：那不再是"一个文件"，而是一张写满统计与结构的地图。

各节怎么分工

先决条件

需要第2章的缓冲管理概念（块缓存、内存上限），以及最基本的"表、列、行"概念。Parquet 如果没接触过也没关系，第3.4节会从零讲起它是什么、为什么值得作为中间格式。

读本章时手里最好有一份真实数据可以边读边看：四节的每个机制都配了可以亲手执行的观察命令（看物理布局、看编码、看日志状态、做格式对比），存储这件事的体感来自"亲眼看见字节怎么摆"。另外提醒一句，本章与第2章是配套关系——内存里块缓存的"块"就是本章行组的"块"，缓冲管理器调度的是这里写下去的数据。两章联读时你会发现第2章悬着的几个"为什么"（比如为什么块缓存能整块释放）在本章落地。

往下走到哪

存储布局与执行引擎是一体两面：本章讲"数据怎么摆"，下一章讲"查询怎么跑"，中间的桥梁是索引与统计信息——行组级别的统计如何支撑查询优化器的剪枝决策，将在第4.4节接棒。主线案例的全年 CSV 在本章末尾完成向列式存储的迁移，为第4章的提速会诊备好场地。