03. SQLite vs MySQL/PostgreSQL

本节目标：学完本章你能用“架构图”在脑子里区分 SQLite 和 MySQL/PostgreSQL，明白它们不是谁大谁小，而是两类不同的东西，并知道按什么维度做选择。

这一章我们不贬低任何一方的“对手”，只做客观对比：把 SQLite 和最常见的两款客户端/服务器数据库（MySQL、PostgreSQL）摆在一起，从架构到适用场景看清楚差异。理解了这些，你选型时就不会被“SQLite 是不是不够专业”这类误解带偏。

核心差异：有没有“服务器进程”

这是所有差异的总根子。

SQLite：没有独立的服务器进程。数据库引擎以代码库的形式直接运行在你的应用程序进程里，程序通过函数调用读写磁盘上的那个数据库文件。
MySQL / PostgreSQL：有一个常驻的服务器进程（daemon）。你的应用程序是“客户端”，它通过 TCP/IP（或本地 socket）把 SQL 请求发给服务器，服务器进程再去读写它管理的数据文件，再把结果返回。

用图类比：

SQLite 模式：你（应用）自己翻开笔记本（数据库文件）写。
MySQL/PostgreSQL 模式：你（应用/客户端）打电话给图书馆管理员（服务器进程），请他帮你查、帮你记，他才去翻书库（数据目录）。

所以你会看到，SQLite 根本没有“连接服务器”的概念——你打开一个文件就算“连上了”；而 MySQL 你要先 mysql -h 主机 -u 用户 -p 去连远端的服务。

数据库是不是“一个文件”

SQLite：整个数据库 = 一个文件（如 app.db）。复制、备份、分发这个文件，数据库就跟着走了。跨平台、格式稳定。
MySQL / PostgreSQL：数据由服务器进程管理，通常散落在特定的数据目录里（一堆表空间、日志、索引文件），你不能随手拎出“某个数据库文件”单独拷走，必须通过服务器提供的导出/备份工具来处理。

这带来运维上的根本不同：SQLite 的“部署”就是把文件放对地方；服务器数据库的“部署”包括安装服务、初始化数据目录、起停服务、做备份策略。

并发模型：单写者 vs 多连接

这是性能选型的关键，必须讲清。

SQLite 的并发：采用库级写锁（database-level write lock）。同一时刻，只允许一个连接做写操作，其他写操作必须等待；但多个连接可以同时读。它的设计哲学是“读很多、写不挤”。在 WAL（Write-Ahead Logging，预写日志）模式下，读写还能在一定程度上并发。
MySQL / PostgreSQL 的并发：服务器进程能同时服务成百上千个客户端连接，配合行级锁（row-level locking）、多版本并发控制（MVCC）等机制，大量写操作可以并行落在不同行/不同表上，扛得住高并发。

Note

别把“SQLite 只能一个写者”理解成“SQLite 很弱”。对它的目标场景（本地、单机、低并发写）来说，这个模型简单又高效；而且 SQLite 内部用非常细的锁协议尽量减少写者饥饿。它只是不适合“很多客户端同时狂写”的场面，那本来也不是它要解决的问题。

部署、运维与扩展

维度	SQLite	MySQL / PostgreSQL
是否需要安装服务	不需要	需要安装并启动服务器
配置文件	无	有（my.cnf / postgresql.conf 等）
用户与权限体系	无（靠文件权限）	有（多用户、角色、库/表/列级权限）
备份方式	复制文件 / `.dump`	逻辑导出（mysqldump 等）或物理备份
横向扩展（加机器）	不支持，单机文件	支持主从、集群、分片
网络访问	不面向远程多客户端	天生面向远程多客户端

可以看到，服务器型数据库把“管理复杂度”换来了“规模与并发能力”。SQLite 把“管理复杂度”降到了零，代价是规模与并发有天花板。

功能完整度

三者在**核心 SQL（SELECT/INSERT/UPDATE/DELETE、JOIN、聚合、子查询、事务）**上高度一致，日常用起来感觉差不多。差异主要在“高级特性”：

存储过程 / 触发器丰富度 / 自定义函数：PostgreSQL 最强，MySQL 次之，SQLite 有触发器但定位轻量。
外连接：SQLite 只支持 LEFT JOIN；MySQL/PostgreSQL 支持 RIGHT、FULL。
JSON、全文检索、窗口函数：三者现代版本都支持，但 SQLite 的这些能力以**扩展（extension）**形式提供（如 json1、FTS5，3.53.4 基线已默认包含），用法略有不同。
类型系统：SQLite 是动态类型+类型亲和性（详见后续章节）；MySQL/PostgreSQL 是更传统的静态/强类型系统。

Warning

网上有些过时资料会把 SQLite 的类型说成“有 DATE/TIME/DATETIME/TIMESTAMP 类型”——这是错的。SQLite 只有 5 种存储类（NULL / INTEGER / REAL / TEXT / BLOB），日期时间通常用 TEXT（ISO8601 字符串）、REAL（儒略日）或 INTEGER（Unix 时间戳）来存储，再靠日期函数去解析和计算。本章对比时请始终记住这一点，别被旧资料带偏。

什么时候选 SQLite

应用内本地存储、单机程序、移动/桌面 App；
原型、测试、CI 里的临时库；
读多写少、并发量小的中小型网站（很多个人博客、小工具后台其实跑得挺好）；
把数据当作“文件”来分发或版本管理的场景。

什么时候选 MySQL / PostgreSQL

高并发写入、大量远程客户端同时访问的后端服务；
需要多用户权限体系、存储过程、复杂报表分析；
数据量大到需要分库分表、主从复制、在线扩展；
团队需要专业的备份、监控、高可用方案。

它们其实可以“合作”

现实里 SQLite 和服务器数据库常常并存而非二选一：比如一个系统用 PostgreSQL 当中心库，同时在每个边缘设备/手机上用 SQLite 做本地缓存与离线库，等联网再把数据同步回中心。这种“中心服务器 + 边缘 SQLite”的搭配非常常见。

类比小结

SQLite = 你随身带的笔记本：随身、即开即写、不用门禁，但没法让全校同时来翻。
MySQL/PostgreSQL = 市中心的图书馆：有管理员、有门禁、能同时服务成千上万人，但你要先“连上去”才能办事。

两者没有高低，只有“合不合适”。选型时别问“哪个更专业”，而要问“我的数据谁来用、怎么用、并发多大”。把这个想明白，本章的目的就达到了。

Tip

一个小经验：如果你是在学 SQL、写练手项目、做个人工具，直接用 SQLite，省下的环境配置时间能多写好几个功能；等项目真长到“需要服务器”了，再把数据迁移过去也不迟——SQL 语法大部分是通用的。