乐闻世界logo
6月1日 00:42

SQLite 有哪些核心特点？适合放在哪些项目里？

SQLite 的核心特点可以用一句话概括：它把一个完整的关系型数据库做成了可嵌入的本地库。你不需要启动数据库服务器，也不需要配置账号和端口，应用直接读写一个数据库文件。这种设计让 SQLite 在移动应用、桌面软件、IoT 设备、命令行工具和小型网站里非常常见。

零配置和单文件是最大优势

SQLite 不需要安装服务，数据库通常就是一个 .db 文件。备份、复制、随应用分发都很方便，开发环境也更容易复现。比如你可以直接用命令行打开文件：

bash
sqlite3 local.db
.tables
.schema user

单文件也有边界。它很适合本地磁盘，不适合多个机器通过网络文件系统同时写。网络文件锁不稳定时，轻则报锁错误，重则出现一致性风险。

小而完整，不等于玩具数据库

SQLite 支持事务、索引、视图、触发器、外键、窗口函数、CTE、JSON 函数和全文搜索扩展。对于很多中小型应用，它提供的能力已经足够。它的延迟很低，因为应用和数据库之间没有网络往返；查询本地小数据集时，体验往往比远程数据库更快。

sql
PRAGMA foreign_keys = ON;
CREATE TABLE note (
  id INTEGER PRIMARY KEY,
  title TEXT NOT NULL,
  body TEXT NOT NULL,
  updated_at TEXT NOT NULL
);
CREATE INDEX idx_note_updated ON note(updated_at DESC);

外键默认是否开启要看连接配置，实际项目里建议每次建连后显式设置。很多“SQLite 不可靠”的抱怨，最后都能追到约束没开、事务没包、锁没处理。

它适合什么，不适合什么

适合 SQLite 的场景通常有几个共同点：部署环境简单，数据主要归单个应用或单个用户所有，写入并发不高，希望减少运维依赖。移动端 App 的离线数据、本地搜索索引、浏览器插件配置、桌面软件项目文件、小型内部工具都很典型。

不适合的场景也很明确：大量用户同时写入、多个应用服务器共享同一个写库、需要细粒度数据库权限、需要内置复制和故障转移。SQLite 可以服务线上系统的一部分，但不应该被硬塞进所有数据库角色里。

追问

SQLite 为什么说是 serverless？

这里的 serverless 不是云函数那个意思，而是没有独立数据库服务器进程。数据库引擎作为库链接到应用里，应用通过文件系统直接访问数据文件。好处是部署极简、延迟低，坏处是连接管理、访问权限和并发边界要由应用自己承担。取舍很清楚：少一层服务，就少一层运维，也少了一些集中治理能力。

SQLite 的性能到底好不好？

在本地读、小事务写和中小数据量场景下，SQLite 性能很好，尤其省掉网络开销后很占优势。慢通常出现在没有索引、频繁单条提交、长事务占锁或把它放到不适合的网络存储上。批量写入时用事务包起来，差距会非常明显。边界是高并发写入和复杂跨用户查询不是它的主战场。

单文件数据库备份是不是直接复制就行？

没有写入时直接复制通常可以；有写入时，最好使用 SQLite 的在线备份 API，或者通过 .backup 命令。WAL 模式下还要注意主数据库文件、-wal 和 -shm 文件之间的一致性。踩坑点是只复制了 .db，漏掉 WAL 里的最新提交，恢复后发现数据少了一截。保守做法是先 checkpoint，再按推荐方式备份。

SQLite 适合团队协作系统吗？

如果团队协作只是少量用户、低频写入、单机部署，可以评估。只要变成多实例 Web 服务、多人同时编辑、需要权限审计和高可用，就更适合 MySQL 或 PostgreSQL。SQLite 的优势是简单，不是替代所有服务器数据库。项目早期可以用它降低复杂度，但要提前想好数据增长和迁移边界。

标签：Sqlite