SQLite 是什么：为什么几乎所有手机 App 都在用它

MySQL、PostgreSQL 这类数据库需要单独安装、启动一个服务进程才能用，但手机 App、桌面软件里悄悄跑着的数据库大多数是 SQLite——它是一种完全不同思路的"嵌入式数据库"。

目录

1. 嵌入式数据库：没有独立服务进程
2. 单文件存储：一个 .db 文件就是整个数据库
3. 为什么移动 App 几乎都用 SQLite
4. SQLite 的局限：不适合什么场景

1. 嵌入式数据库：没有独立服务进程

MySQL、PostgreSQL 这类"客户端-服务器"架构的数据库，需要单独运行一个持续监听的服务进程，应用程序通过网络协议（即便是本机通信，也走的是进程间通信/网络接口）连接这个服务进程来读写数据。SQLite 完全不是这个模式——它是一个嵌入式数据库引擎，以库文件的形式直接被应用程序调用，数据库的读写逻辑就在应用程序自己的进程里执行，不存在单独启动、需要维护的数据库服务进程。这个架构差异是理解 SQLite 所有其它特性的基础。

2. 单文件存储：一个 .db 文件就是整个数据库

SQLite 数据库在磁盘上就是一个单独的文件（常见后缀 .db、.sqlite），这个文件里包含了所有的表结构、索引、数据——不像 MySQL 那样需要一整套服务配置、多个数据文件和日志文件。这带来了极强的可移植性：想复制、备份、迁移一个 SQLite 数据库，直接复制这一个文件即可，不需要处理复杂的导出导入流程或者担心版本兼容问题。这也是为什么在浏览器里能直接"打开"一个 SQLite 文件查看内容——本质上就是读取这一个文件，用 WebAssembly 编译的 SQLite 引擎在内存里加载解析它的内部结构。

3. 为什么移动 App 几乎都用 SQLite

移动 App、桌面软件、浏览器内部（Chrome、Firefox 都在用 SQLite 存储历史记录等本地数据）大量使用 SQLite，核心原因是它天然契合这类场景的需求：不需要单独部署维护一个数据库服务（用户的手机上不可能，也不应该要求额外运行一个数据库服务进程）、零配置（应用启动时直接打开本地文件即可使用，不需要连接字符串、账号密码这类配置）、足够轻量（整个引擎编译后体积很小，适合塞进移动 App 的安装包里）。这些特性和"客户端-服务器"数据库的设计目标（支持高并发、多客户端同时访问、复杂权限管理）完全是两个方向，SQLite 从设计之初就不是为了替代 MySQL 这类服务器数据库，而是专门为"单机、单进程本地存储"这类场景优化的。

4. SQLite 的局限：不适合什么场景

正因为架构定位不同，SQLite 也有明显不适合的场景：多个进程或多台机器同时高并发写入——SQLite 对并发写入的支持相对有限（同一时刻通常只允许一个写操作），不像 MySQL/PostgreSQL 那样为高并发多用户访问场景做了大量优化；需要通过网络远程访问的场景——SQLite 是本地文件访问模式，没有内置的网络服务能力，如果需要多台服务器共享同一份数据，SQLite 天然不适合。理解这些边界，才能明白"什么时候该用 SQLite，什么时候必须上 MySQL/PostgreSQL"——这本质上是"单机嵌入式"和"网络化服务端"两种数据库架构在设计目标上的根本区别，不是简单的"功能强弱"之分。

在线工具：SQLite查看