数据库系统概论

从文件系统到数据库

文件系统的本质局限

操作系统提供的文件 API 本质上是对磁盘块的抽象映射，它在解决数据持久化问题的同时，也带来了几个核心难题。

第一个问题是数据冗余与不一致。当多个应用程序各自维护独立的数据文件时，同一份数据往往被重复存储。设想一个电商系统中，用户基本信息在订单模块、支付模块、物流模块中各有一份副本，任何一次用户信息的变更都需要同步更新多个文件，而一旦某个模块的更新失败，数据就进入了不一致状态。这种冗余不仅浪费存储空间，更重要的是维护成本呈指数级增长。

第二个问题是并发控制的缺失。虽然操作系统提供了文件锁（flock）机制，但它的粒度太粗——通常只能锁定整个文件。在高并发场景下，这会导致严重的性能瓶颈。更糟糕的是，即便使用了文件锁，也无法解决"读-修改-写"这类原子操作的问题。例如两个进程同时读取同一个计数器文件，都读到值 10，各自加 1 后写回 11，而不是预期的 12。这正是数据库需要通过原子操作和锁机制来解决的典型问题。

第三个问题是数据独立性的缺失。在文件系统中，应用程序代码与数据的物理存储格式紧密耦合。如果将数据从文本格式改为二进制格式，或者修改了文件的结构，所有访问该文件的代码都需要相应修改。这种耦合使得数据演进变得极其困难。

数据库系统的解决方案

数据库系统通过在文件系统之上构建一个中间抽象层，系统性地解决了上述问题。

数据模型将物理存储与逻辑视图完全分离。无论底层使用 B+ 树还是 LSM 树组织数据，应用程序始终通过关系模型（表、行、列）来操作数据，这就是逻辑独立性。同时，存储引擎可以在不影响上层逻辑的情况下调整物理存储方式，这就是物理独立性。

事务机制提供了 ACID 保证，确保并发操作的正确性。事务将一系列操作打包成一个原子单元，要么全部成功，要么全部失败。这通过预写日志（WAL）和锁机制实现，我们会在后续章节深入讨论。

查询优化器解放了开发者。开发者只需要声明"我要什么数据"，而不需要关心"如何高效获取数据"。优化器会自动选择最优的执行计划，这背后是复杂的统计信息和代价估算模型。

并发控制实现了细粒度的锁和多版本并发控制（MVCC）。多个事务可以同时读写同一张表的不同行，甚至可以同时读取同一行而互不阻塞（通过多版本快照）。

数据库系统的组成架构

连接层

连接层负责处理客户端的连接请求，管理连接池，进行身份认证和权限校验。MySQL 的连接器、PostgreSQL 的 libpq 都属于这一层。连接层还需要处理网络协议的解析，MySQL 使用自定义的二进制协议，PostgreSQL 支持多种协议包括前端/后端协议。

服务层

服务层是数据库的大脑，包含多个核心组件。

查询解析器将 SQL 文本解析成抽象语法树（AST）。它会检查语法错误，识别关键字、表名、列名等语法元素。

预处理器进行语义分析，检查表是否存在、列是否有效、用户是否有权限等。它还会展开视图引用，处理子查询嵌套。

优化器是服务层最复杂的组件，它需要从无数种可能的执行计划中选择代价最小的一个。基于规则的优化（RBO）应用一些启发式规则，如"投影下推"、"谓词下推"。基于成本的优化（CBO）则依赖统计信息估算每种操作的成本，包括磁盘 I/O 次数、CPU 计算量、内存消耗等。

执行器按照优化器生成的执行计划调用存储引擎的接口获取数据。对于 InnoDB，它会调用定位记录、读取记录、更新记录等底层 API。

存储引擎层

存储引擎层负责数据的物理存储和检索，是数据库的核心。MySQL 支持插件式存储引擎架构，常见的有 InnoDB（支持事务、行锁）、MyISAM（表锁、不支持事务）、Memory（内存存储）。PostgreSQL 则采用统一的存储引擎，但其内部同样分层。

存储引擎需要解决三个核心问题：数据如何高效存储、如何快速查找、如何保证持久性。这三个问题分别对应存储结构、索引结构和日志系统。

文件系统层

数据库最终将数据持久化到磁盘文件中。不同的存储引擎有不同的文件组织方式。InnoDB 使用表空间（tablespace）管理数据文件，包括系统表空间、独立表空间、撤销表空间、临时表空间等。每个表空间包含若干个段（segment），段由若干个区（extent）组成，区是连续的页（page）集合。

为什么需要数据库而非文件

回顾数据库系统的核心价值，我们可以总结为以下几点：集中管理消除了数据冗余和不一致，事务机制保证了数据完整性，并发控制支持多用户同时访问，查询优化器简化了应用开发，索引技术实现了高效检索，权限管理提供了细粒度的访问控制。

这些能力的代价是复杂的系统架构和显著的运行时开销。但对于任何需要持久化存储数据的应用来说，这些代价是值得的。理解数据库的底层实现，能够帮助我们更好地使用它，在性能调优时做出更明智的决策。