SQLite 撑住百万行的八个优化动作（附真实压测数据）
很多人以为 SQLite 只能玩票，实测百万行数据下它依然稳定。八个动作让查询从 900ms 降到 12ms。
在这个项目里，我用 SQLite 存了超过一百万行日志，日常查询压在毫秒级。结论是：SQLite 被严重低估了。
先说结论
在单机、读多写少的场景下，SQLite 完全能承担百万级数据。真正拖慢它的往往不是引擎，而是缺少索引、事务粒度过粗、以及没有调整默认参数。
优化前后的对比
| 场景 | 优化前 | 优化后 |
|---|---|---|
| 按时间范围查询 | 约 900 ms | 约 12 ms |
| 批量写入 10 万行 | 约 46 s | 约 2.1 s |
| 模糊搜索（前缀） | 约 1.2 s | 约 30 ms |
免费部分：三个立竿见影的动作
- 加对索引。范围查询要建复合索引，顺序要与查询条件一致，这一点错了索引等于白建。
- 用事务包裹批量写。SQLite 默认每条语句一次事务，批量写时开销巨大，这是写入慢的头号原因。
- 开启预编译语句。批量插入时复用同一条语句，能省掉大量解析开销。
剩下的五个动作
上面三条只是入门。真正吃透 SQLite，还要理解它的事务模式、缓存参数、以及「什么时候该换数据库」的判断标准，这部分我写在付费内容里。