架构总览

你每天都在用 MySQL、PostgreSQL——但你有没有想过，当你敲下一条 SELECT * FROM users 时，数据库内部到底发生了什么？本课程带你亲手从零构建一个能运行 SQL 的数据库，揭开这个黑盒。

1. 你将构建什么

学完本课程，你将拥有一个自己写的 SQL 数据库——它能理解并执行真正的 SQL 语句：

-- 创建表
CREATE TABLE users (id INT, name VARCHAR NOT NULL, age INT DEFAULT 0);

-- 插入数据
INSERT INTO users VALUES (1, 'Alice', 28);
INSERT INTO users (id, name) VALUES (2, 'Bob');

-- 查询数据
SELECT * FROM users;

你的数据库将包含一个 SQL 数据库的核心模块：

而且，你会用 Go、Rust、Java、C++ 四种语言同步实现——同一个架构，四种视角，选你最擅长的语言入手，或者用不熟悉的语言挑战自己。

与真实数据库的对比

你日常使用的 MySQL、PostgreSQL、SQLite 虽然功能丰富、代码量巨大（PostgreSQL 超过 100 万行 C 代码），但它们的核心架构是相通的——都遵循"SQL 前端 → 执行引擎 → 存储引擎"的分层模式：

几个主流数据库的架构特点：

• PostgreSQL：经典的分层架构，存储引擎基于堆表（Heap Table）+ 索引，MVCC 通过多版本元组实现
• MySQL/InnoDB：SQL 层和存储引擎解耦（可插拔存储引擎），InnoDB 使用聚簇索引 + Buffer Pool
• SQLite：嵌入式架构，无需独立服务进程，整个数据库存储在单个文件中，使用 B-tree 作为底层存储结构

2. SQL 执行全景

当你敲下一条 SQL，数据库内部会按照这条流水线依次处理：

五个模块，各司其职：

1. Lexer（词法分析）：将 SQL 字符串拆分为 Token 流
2. Parser（语法分析）：将 Token 流组织成 AST（抽象语法树）
3. Planner（查询计划）：分析 AST，生成执行计划
4. Executor（执行引擎）：按照执行计划获取和处理数据
5. Storage Engine（存储引擎）：负责数据的读写和持久化

这条流水线就是 MySQL、PostgreSQL、SQLite 等所有 SQL 数据库共享的核心架构。

本课程的数据库架构

我们在课程中实现的 SQL 数据库，基本涵盖了上述所有核心组件。下面是整体架构图：

整体分为两大部分：

• SQL Engine（左侧）：负责 SQL 的解析和执行。用户的 SQL 请求到达后，依次经过 Parser（解析）→ Planner（生成执行计划）→ Optimizer（优化）→ Executor（执行），最终从存储引擎中进行数据的增删改查。
• Storage Engine（右侧）：负责数据的存储和事务管理。最上层是 MVCC 事务层，提供快照隔离的并发控制；下层是 KV Storage 接口，支持内存和磁盘两种存储引擎实现。

接下来我们逐层拆解每个模块。

3. 逐层拆解

Lexer —— 把 SQL 拆成"词"

Lexer 是流水线的起点，逐字符扫描 SQL 字符串，将其切分为 Token：

SELECT id FROM users WHERE age > 18
  ↓
[Keyword(SELECT), Ident("id"), Keyword(FROM), Ident("users"), Keyword(WHERE), Ident("age"), GreaterThan, Number("18")]

每个 Token 包含类型（关键字、标识符、数字、符号）和值（原始文本）。Lexer 不理解语义——SELECT SELECT FROM FROM 对它来说完全合法。

Parser —— 构建语法树

Parser 接收 Token 流，组织成一棵 AST（抽象语法树），用树状结构表达 SQL 的逻辑含义：

AST 把 SQL 的结构信息完整保留下来——查哪些列、从哪张表、过滤条件是什么——后续模块只需要遍历这棵树。

Planner —— 生成执行计划

Planner 拿到 AST 后，生成一份执行计划（Plan）。执行计划通常以树状结构的形式表示，其中包含了执行查询所需的各种操作，如索引扫描、表扫描、连接操作等。

Optimizer —— 选择最优路径

Optimizer 负责根据执行计划生成的各种执行路径，选择最优的执行方案。它的目标是在保证查询结果正确性的前提下，尽可能降低查询的成本——包括 CPU、内存和 IO 等资源的消耗。

为了达到这个目标，Optimizer 会考虑多种因素：

• 索引的利用——有索引就走索引扫描，比全表扫描快得多
• 连接顺序的优化——不同的 JOIN 顺序可能导致数量级的性能差异
• 统计信息——根据表的数据分布估算各种执行路径的代价

Executor —— 真正干活的人

Executor（执行器）负责具体去执行执行计划中的各个节点。一般的执行器模型采用推（Push）或者拉（Pull）的方式。

最常见的是基于 Pull 的 Volcano 模型（火山模型），会从最顶层的节点开始执行，循环拉取下层节点的结果，直到完全执行并返回。每个操作符实现一个 Next() 方法，像流水线一样串联：

• Scan：从存储引擎逐行读取数据
• Filter：根据 WHERE 条件过滤行
• Projection：只选取需要的列
• Sort：对结果排序（ORDER BY）
• Aggregate：聚合计算（COUNT、SUM 等）

Transaction —— 事务保障

事务是数据库系统中的重要概念，它是一系列数据库操作的逻辑单元，要么全部执行成功，要么全部执行失败。事务管理组件负责确保事务的 ACID 属性：

本课程会实现基于 MVCC（多版本并发控制）的快照隔离事务，在多版本的基础上，让多个事务可以并发读写而不互相阻塞。

Storage Engine —— 数据的家

存储引擎是数据库内核中负责管理数据存储和检索的组件，它负责将数据存储到物理存储介质中，并提供高效的数据访问接口。一个典型的存储引擎包含以下关键组件：

本课程的存储引擎采用 KV 接口设计，上层是 MVCC 事务层，下层支持内存和磁盘两种实现。先用内存 KV 存储快速跑通整个架构，后续再实现基于磁盘的持久化存储引擎。

4. 一条 SQL 的完整旅程

现在把所有模块串起来。当你输入 SELECT id FROM users WHERE age > 18; 时：

1. Lexer 扫描字符串，输出 Token 流：[SELECT, id, FROM, users, WHERE, age, >, 18]
2. Parser 消费 Token 流，构建一棵以 SELECT 为根的 AST
3. Planner 分析 AST，生成执行计划：扫描 users 表 → 过滤 age > 18 → 投影 id 列
4. Executor 按照计划，调用 Storage Engine 逐行读取数据
5. Storage Engine 返回数据，Executor 将最终结果交给用户

每个模块只负责一件事，通过清晰的接口传递数据。这种分层架构带来三个好处：

• 关注点分离：每个模块只处理自己的问题
• 可替换性：换掉存储引擎不用改 Parser
• 可测试性：每个模块可以独立测试

5. 课程的构建策略

本课程采用"先跑通、再完善"的策略：

这样你在第 9 章就能看到一条 SQL 从输入到结果返回的完整过程——而不是写了一堆代码却看不到效果。每一章都在上一章的基础上增量开发，你始终有一个能运行的系统。