02. 为什么选 SQLite

上一章我们说 SQLite 是“随身的笔记本”。但笔记本再好，也不是所有场合都该用它。这一章就来解决一个最实际的问题：到底什么时候该选 SQLite，什么时候不该？

它最擅长的事：适用场景

1. 嵌入式与本地应用

手机 App、桌面软件（Windows/macOS/Linux 原生程序）、浏览器扩展，几乎都需要“在本地存点东西”——用户的偏好设置、草稿、缓存、离线数据。这种场景 SQLite 是默认答案：它直接以文件形式躺在应用沙盒里，随开随用，不占额外进程。

2. 边缘设备与 IoT

路由器、智能家电、车载设备、传感器网关，这些“边缘（edge）”设备往往 CPU 弱、内存小、还经常断电。SQLite 不到 400KiB、自包含、断电安全（ACID），简直是为这类环境量身定做。

3. 单机程序与本地存储

很多小工具就是一个人用、一台机器跑，比如个人记账本、本地通讯录、单机小游戏存档。给这种程序去搭一套 MySQL 服务器，属于“杀鸡用牛刀”。SQLite 一个文件搞定，迁移还只要复制文件。

4. 原型开发与测试

写新功能做原型时，你最不想把时间花在“装数据库、建用户、配权限”上。SQLite 零配置，启动时连文件名一指就能建库，跑完测试删掉文件即可，干净利落。CI（持续集成）流水线里也常用它做单元测试的临时数据库。

5. 跨平台与数据文件交换

因为库文件跨平台、格式稳定，SQLite 经常被当作应用文件格式来用——你存的不是一个“数据库”，而是一个“文档”。比如很多笔记软件、财务软件，它的 .db 文件其实就是“这个软件的一本账本”，你可以像传一个 Word 文档那样把它发给别人。

6. 缓存与中间结果

把网络请求的结果、计算的中间产物缓存在本地 SQLite 里，下次启动直接读，体验更顺滑、也更省流量。它比自己手写一堆散文件要规整，又比上服务器轻得多。

它的边界：什么时候不该用

选型的关键，往往是知道它不适合什么。下面这几条是 SQLite 的明确边界，踩到就要换方案。

边界一：高并发写入

SQLite 采用库级写锁：同一时刻只能有一个写者在写，其他写操作得排队。对于“一天几十条数据的本地应用”无所谓；但如果是“几千个用户同时下单、每秒几百次写”的网站后端，SQLite 会立刻成为瓶颈。这种高并发、多写者的场景，应当用 MySQL、PostgreSQL 这类客户端/服务器数据库。

边界二：需要被很多人通过网络同时访问

SQLite 是为“一个应用、一个进程、本地访问一个文件”设计的。虽然它支持多个进程同时读，但“让成百上千台远程机器通过网络连同一个 SQLite 文件”并不是它的设计目标（网络文件系统上跑 SQLite 还会带来锁与一致性问题）。多客户端远程访问，请上服务器型数据库。

边界三：超大规模数据量

单个 SQLite 数据库文件理论上限约 281TB，听起来很大，但实践中当数据量和并发都上来后，单一文件 + 库级锁的模型会遇到性能和运维天花板。海量数据、需要分库分表、需要在线水平扩展的场景，不是 SQLite 的菜。

边界四：需要精细的访问权限控制

SQLite 的“权限”就是底层操作系统对那个文件的读写权限——谁能读这个文件、谁能写这个文件。它没有像 MySQL 那样的 GRANT/REVOKE 多用户、多角色、列级权限体系。如果你的需求是“给用户 A 只让看某几张表、给用户 B 能改某列”，SQLite 给不了，得上服务器型数据库。

边界五：某些高级 SQL 特性不支持

为了轻量，SQLite 有意不支持一部分 SQL 标准特性，例如：

• 只实现了 LEFT OUTER JOIN，没有 RIGHT OUTER JOIN 和 FULL OUTER JOIN；
• 视图（VIEW）是只读的，不能在视图上直接 INSERT/UPDATE/DELETE；
• ALTER TABLE 的“改列类型、直接加约束”仍不支持（注：3.25.0 起已支持重命名列、3.35.0 起已支持删除列，能力在逐步增强）。

这些对大多数入门和嵌入式场景影响不大，但写复杂分析SQL时要心里有数。

一张选型速查表

你的场景	选 SQLite？	理由
手机/桌面 App 本地存储	✅ 强烈推荐	嵌入式、零配置、文件即库
个人小工具、单机程序	✅ 推荐	太轻量，搭服务器不划算
原型 / 单元测试 / 临时库	✅ 推荐	秒级建库、删文件即清
缓存、配置、离线数据	✅ 推荐	一个文件搞定，易迁移
高并发写（如电商下单）	❌ 别用	库级写锁扛不住
大量远程客户端同时访问	❌ 别用	非 serverless 设计
多用户精细权限管理	❌ 别用	无 GRANT/REVOKE
海量数据 + 水平扩展	❌ 谨慎	单文件模型有上限

为什么很多人“用错了”又“离不开”

有意思的是，SQLite 的官方文档自己就写了一篇《Appropriate Uses For SQLite》（合适的用途），专门劝大家“别把它当服务器数据库”。但现实里它却是部署量最大的数据库引擎——因为绝大多数软件的“数据库需求”其实是本地的、单机的、低并发的，正好落在 SQLite 的甜蜜区。

记住一句话：SQLite 不是“小号 MySQL”，它是一种不同的东西。 它解决的是“应用内、本地、轻量、可靠地存数据”的问题；MySQL/PostgreSQL 解决的是“多客户端、高并发、集中管理”的问题。两者不是替代关系，而是各管一片。

类比小结

还是用“笔记本 vs 图书馆”：

• 你自己记日记、列清单、写草稿 → 笔记本（SQLite）最舒服。
• 全校师生同时来借书还书、还要分权限 → 必须图书馆（MySQL/PostgreSQL）。

选型的艺术，就是先想清楚“谁来用、怎么用、并发多大”，再决定掏笔记本还是去图书馆。下一章我们把这两类数据库的架构差异摊开来对比，让你看得更透。