SQLite内核与优化

SQLite内核与优化 · 教程导读

「Embedded Database」（嵌入式数据库）这个词，在多数人嘴里只意味着"小"。翻开这本教程你会发现，它真正意味着的是另一种架构立场：数据库不驻留在远端机房，而是作为一组库函数，链接进你的应用进程，与业务代码共享同一份内存、同一个崩溃边界、同一套部署单元。MySQL 与 PostgreSQL 把数据库当作一个需要专人照料的"服务"，SQLite 则把它当作一个可以直接调用的"组件"。这本教程的全部内容，都从这条架构分野出发：同一件事——存一页数据、跑一条 SQL、提交一个事务、建一个索引——三个引擎各自是怎么做的，为什么不同，差异如何影响你的优化决策。

我们不打算按概念词典的方式逐条讲解 SQLite 内核，而是采用对比驱动的主线：每一章都从"同一个问题，三个引擎的三种答案"切入。讲文件格式时，会把 SQLite 的单文件布局与 MySQL 的多文件表空间、PostgreSQL 的 base 目录摆在一起；讲事务时，会把回滚日志、WAL 追加日志与 InnoDB 重做日志的写入路径画成对照图；讲查询计划时，会并排展示 SQLite 的字节码清单、MySQL 的 EXPLAIN 表格与 PostgreSQL 的计划树。比较不是点缀，而是理解机制的最短路径——当你能说清一个引擎"为什么不做另一件事"，你才算真正理解了它做了什么。

这本教程适合谁

三类读者会从中拿到想要的东西。第一类是把 SQLite 用在移动应用、桌面软件、嵌入式设备或小型服务里的开发者，他们需要知道 PRAGMA journal_mode=WAL 背后发生了什么，而不是只背结论。第二类是做过 MySQL 或 PostgreSQL、好奇"如果把数据库塞进进程里会怎样"的后端工程师，对比主线会让他们已有的知识直接成为学习 SQLite 的杠杆。第三类是为面试或系统设计做准备的学生——B+ 树层数估算、WAL 帧结构、索引选择性计算，这些正是内核面试的高频考点，本册给出了可以动手复算的完整过程。

阅读门槛不高：会基本 SQL，了解"索引能加速查询"这类常识即可。涉及 C 代码的地方，只需读懂函数调用顺序，不需要你写过 C。

全册知识地图

下面这张图给出了八章之间的依赖关系。虚线以上是"存储与执行"的机制层，虚线以下是"把机制用对"的实践层；箭头指向后续章节，表示"学懂这里再去那里"。第 1、2 章是地基：不知道页是什么，后面的一切优化都无从谈起。

图：全册知识地图与学习路径

三条主线贯穿全图。机制线沿第 1、2、3、4 章推进：先是架构与文件（SQLite 是什么），再是页与树（数据住哪里），再是编译与虚拟机（SQL 怎么执行），最后是事务与日志（怎么不出错）。优化线是第 5、6 章：索引是数据结构层面的加速，优化器是算法层面的加速，两章建议连读。运维线是第 7、8 章：内存与缓存决定稳态性能，备份与安全决定敢不敢上线。

三十年来三个引擎各自走了哪条路

对照不仅发生在空间上（三种架构），也发生在时间上。SQLite 出现得比 MySQL 晚、比 PostgreSQL 的开源化晚，但它跳过了"客户端-服务器"这个阶段，直接长成了另一种形态。

读完这张时间线你会发现一个反直觉的事实：SQLite 的代码量只有 PostgreSQL 的几十分之一，却覆盖了关系数据库约三分之一的核心语义。它不是"功能少所以简单"，而是"砍掉一切可以砍的东西之后剩下的必然"。这也是为什么研究它的内核特别划算——你能在可消化的篇幅里看完一个数据库的全部骨架。

怎么读这本教程

每章的章首页都有一张本章地图和可检验的学习目标；每节开头的百来字会说明它在知识体系里的位置——承接哪一节，通往哪一节。对比内容以三种形式出现：对照表（结构化差异）、对照实验（同一条 SQL 在三库的不同输出）、机制对照图（写入路径、锁范围、内存布局的图示）。看到差异时，建议你自己动手复现：装一个三千万字节级别的样例库，跑 EXPLAIN QUERY PLAN，改一个 PRAGMA 再跑一遍——内核知识只有被复算过，才真正属于你。

三个约定。其一，所有命令行示例都在 sqlite3 命令行工具中演示，版本以 3.4x 为基准，老版本的输出格式可能略有差异。其二，涉及 MySQL 时默认 InnoDB 引擎、涉及 PostgreSQL 时默认行存储堆表，这是生产环境的绝大多数场景。其三，本册讲"为什么"，第 8 章的部署实录讲"怎么办"，遇到具体故障时可以直接翻过去查速查表。

一句话定位：读完本册，你应当能对着任何一个 SQLite 数据库文件，说出它的每一块字节在做什么；能预判一条 SQL 会走全表扫描还是索引；能在 WAL 与回滚日志之间、在页缓存大小与内存上限之间，给出有依据的决策——并且能说清 MySQL、PostgreSQL 在同一问题上为什么选了另一条路。