SQLite 才是被低估的数据库：我用它扛住了日均百万请求

上个月有个读者问我，他们小团队想做个数据量不小的工具站，预算有限，DBA 也没有，问我该上什么数据库。我回了一句：先别急着上 MySQL，试试 SQLite。

他当场就愣住了，觉得我在开玩笑。SQLite 不是手机里那个嵌入式小玩意儿吗？能扛住啥？

老实说，我以前也这么想。直到我自己把一个日请求量百万级的服务从 MySQL 迁到了 SQLite，才发现这玩意儿被低估得厉害。

为什么敢用它扛流量

先说清楚，我这里说的百万请求，是读多写少的场景——比如文章缓存、配置中心、用户行为统计的中间结果。这种场景下，SQLite 的读性能真的不虚。它的 B 树索引在单机上的表现，配合 WAL 模式，并发读基本是线性的。我压测的时候，8 核机器上纯读能跑到每秒十几万次查询，延迟稳定在个位数毫秒。

而且它省心啊。不用装服务、不用配账号、不用管连接池，一个文件就是整个库。我部署的时候，直接把 .db 文件跟着代码一起打包进容器，起服务就完事。备份更是简单到离谱：cp 一下文件就是备份，我甚至用 crontab 每十分钟 rsync 一次到另一台机器。

踩过的坑也值得说说

当然，无脑吹没意思，坑我也踩过几个。

第一个坑是写并发。SQLite 同一时刻只允许一个写者，我一开始没注意，业务高峰期批量写入直接报 database is locked。后来把写入全部丢进一个队列串行化，再配合 WAL 和 busy_timeout，问题就没了。

第二个坑是网络盘。千万别把 SQLite 文件放在 NFS 或者 Ceph 这种网络存储上跑，锁机制在分布式文件系统上会出各种诡异问题，我同事就因此丢过数据。老老实实放本地 SSD，稳得很。

第三个坑是查询没走索引。SQLite 的 EXPLAIN QUERY PLAN 太好用了，我每次上线前都会跑一遍，看看有没有全表扫描。有次一个慢查询从 800ms 优化到 8ms，就是加了个复合索引的事。

什么时候别用它

也别误会，SQLite 不是万能钥匙。跨机房多写、超大数据集（几十个 G 往上）、需要在线扩容的场景，还是老老实实换 PostgreSQL 或者 MySQL。我的原则很简单：单机、读多写少、数据量可控，就用 SQLite；否则，换大件。

现在我这个服务跑了快一年，零故障，运维成本约等于零。工具选对了，真的能省掉一大半的烦恼。