1.1 三种引擎的定位对照
1.1 三种引擎的定位对照
本节摘要：SQLite、MySQL、PostgreSQL 的差异首先是架构立场的差异：进程内组件、独立服务、多进程服务。本节从部署形态、进程模型、历史渊源三个维度给三个引擎画像，并给出"什么时候不该用 SQLite"的判断清单——知道边界，比记住特性更重要。
三个引擎的三份档案
先看一份最小说明。同样要"存一张表、查一行数据"，三个引擎给出的答案截然不同：
- SQLite：你的应用链接一个 C 库，数据库就是磁盘上的一个文件。没有端口、没有账号、没有配置文件，
sqlite3_open()返回的句柄就是你和数据库之间的全部关系。 - MySQL：一个常驻的 mysqld 服务进程监听端口（默认 3306），应用通过客户端协议连上去。数据在数据目录里，由服务进程独占管理。
- PostgreSQL：一个常驻的 postmaster 守护进程（默认端口 5432），每来一个连接就 fork 一个后端进程伺候到底。数据放在 base 目录下，按数据库分目录、按表分文件。
三种立场的分野，用一张光谱图看得最清楚：
图：三引擎部署形态光谱
历史渊源解释了立场
三个引擎的出生环境，几乎注定了它们的架构。SQLite 在 2000 年诞生于一个军舰指挥系统的项目：程序跑在一台没有管理员、没有网络的设备上，通用数据库服务根本没地方安装，作者索性把存储层写成了库函数。MySQL 在 1995 年瞄准的是快速崛起的 Web 站点：网站服务器和数据库常常部署在同一台机器上，但 MySQL 依然选择了服务形态，因为它要服务的是"许多动态页面脚本并发访问同一份数据"——多连接共享服务是刚需。PostgreSQL 的血统可以追溯到伯克利的 POSTGRES 研究项目，1996 年开源化时继承了对复杂查询、扩展性和标准符合度的执念，多进程后端模型则来自 Unix 传统："每个连接一个进程，出了问题杀掉一个进程"。
理解这一点有助于你放下一个常见执念："SQLite 是不是 MySQL 的缩水版？"不是。SQLite 从未打算提供服务端能力，它把省下的每一字节内存和每一行代码都花在了嵌入式场景真正需要的性质上：确定性延迟、零配置、单文件可复制、崩溃后自愈。
三维度对照表
下表把三个引擎的关键属性并排放置，建议存下来当作选型速查：
| 维度 | SQLite | MySQL（InnoDB） | PostgreSQL |
|---|---|---|---|
| 部署单元 | 一个 C 库，链接进应用 | mysqld 服务进程 | postmaster + 每连接一个后端进程 |
| 数据形态 | 单一数据库文件（加 WAL 伴生文件） | 数据目录下的共享与独立表空间 | base 目录，每表一到三个文件 |
| 访问方式 | 函数调用 | 客户端协议，网络往返 | 客户端协议，网络往返 |
| 典型延迟量级 | 微秒级（无网络、无调度） | 毫秒级（本机回环也含协议开销） | 毫秒级 |
| 并发写入 | 单写者（WAL 下读写可并行） | 多写者，行级锁加间隙锁 | 多写者，MVCC 多版本 |
| 默认隔离级别 | 串行化语义（快照，WAL 下） | REPEATABLE READ | READ COMMITTED |
| 配置项数量 | 十几个 PRAGMA 起步 | 数百个系统变量 | 数百个 GUC 参数 |
| 备份 | 复制文件或 backup API | mysqldump、物理备份工具 | pg_dump、物理基础备份 |
| 权限体系 | 依赖文件系统权限 | 用户、库、表、列四级授权 | 角色与对象级 ACL |
| 典型数据量 | 数 GB 到数百 GB 内 | 无硬上限，按集群扩展 | 无硬上限，按集群扩展 |
⚠️ 上表是"默认立场"，不是硬边界：SQLite 也能承载几百 GB 的库，MySQL 也能跑在笔记本上。差异在"设计重心"，判断时看你的负载落在哪一侧。
什么时候别用 SQLite
判断清单比赞美清单有用。出现以下任一信号，请直接选服务端数据库：
- 多机写入。两个应用实例同时写同一个 SQLite 文件，要么靠网络文件系统（不可靠，WAL 的共享内存机制在多数网络文件系统上直接失效），要么自己写同步层。这是硬边界，没有巧可取。
- 持续高并发写入。SQLite 的写入是串行的，WAL 模式下写事务依然互斥。实测经验：单机每秒几千个短写入是舒适区，数十万 QPS 的写入型负载请移步 InnoDB。
- 多角色权限。SQLite 没有内置用户体系，谁能读文件谁就全能。需要"这个账号只能看这张表"的合规场景，选 PostgreSQL。
- 数据库需要独立扩缩容。应用和数据库同生死，应用横向扩展十份，数据就要面对十份副本或一个被多方写入的共享存储——两条路都不是 SQLite 设计的赛道。
反过来，移动端本地存储、桌面软件配置与缓存、物联网设备日志、单机网站的只读内容库、测试环境的内存数据库（:memory:），SQLite 都是默认正确答案。
常见问题速答
**SQLite 能当网站数据库用吗？**看流量形态。日均几千单的小型站点、内容基本只读的展示型应用完全够用——单文件、零运维、备份即拷贝。判断信号是写入并发：多进程同时写（比如多个应用容器挂同一个网络盘上的库文件）是红线，纯单机单进程的写入即便每秒几千条也在舒适区内。不少静态站点生成器与个人博客系统的默认存储就是 SQLite，稳定运行多年。
**三个引擎的许可以及它对选型的影响？**SQLite 属于公有领域，可以随意嵌入商业闭源产品，这是它在设备厂商中流行的隐性原因之一。MySQL 由 Oracle 持有，GPL 与商业双授权，闭源产品链接客户端库或分发时要注意合规路径（或选社区分叉）。PostgreSQL 采用类 BSD 许可，商用约束最宽松。嵌入式产品里"无授权焦虑"这个因素，值得和性能因素放在一起称量。
本节要点回顾
- 架构立场先于功能清单：进程内组件与独立服务的差异，推导出并发模型、故障半径、备份方式的一切下游差异。
- 历史解释立场：军舰指挥系统造出了 SQLite，Web 站点造出了 MySQL，伯克利研究传统造就了 PostgreSQL。
- SQLite 的正确心智模型是"带 ACID 语义的本地文件格式库"，不是"迷你服务器"。
- 四条边界信号：多机写入、高并发写、细粒度权限、独立扩缩容——出现即换引擎。
**同一台笔记本上三个引擎能共存吗？**能，且这是学习本册的最佳实验环境：MySQL 与 PostgreSQL 用各自官方安装器装成服务，SQLite 直接用命令行工具，三者互不干扰。给每一库存同一份样例数据（比如公开的唱片数据库样本），跑同一组查询对照计划与耗时——本册的对照实验多数都能在这套环境里复现。资源占用也友好：SQLite 零常驻，另两家的服务在空闲时占用有限。