说实话，第一次接触 SQLite 的人，十有八九会被它那“小身板”骗了。一个只有几百 KB 的嵌入式数据库，怎么能和 MySQL、PostgreSQL 这些“大佬”比性能？但干媒体这些年，我见过太多人因为 SQLite 踩坑。其实，SQLite 慢不是它不行，而是你没用对方法。今天咱们聊聊，怎么用几个土办法让 SQLite 的查询速度提升 10 倍。别小看这个“小不点”，优化好了，它真的能撑起你意想不到的场景。
先说最常见的坑：没建索引。这事儿太普遍了，我见过一个哥们儿把上百万条用户数据塞进 SQLite，查询时直接全表扫描，每次查用户名要等好几秒。SQLite 的 B 树索引机制非常高效，只要给常查询的字段加个索引，速度立马从“爬”变“跑”。比如 ，就这么一句，查询时间从秒级降到毫秒级。不过别上头，索引不是越多越好——写操作会变慢，因为每次插入都要更新索引。经验是：只给 WHERE、JOIN、ORDER BY 里频繁出现的字段加索引，其他字段别碰。
接下来是“事务”这个大杀器。很多新手写 SQLite 时，每条 INSERT 都单独提交，结果插入 10 万条数据要花好几分钟。为啥？因为每次提交 SQLite 都要写磁盘、刷缓存，开销很大。正确的做法是把一堆 INSERT 包在一个事务里，一次性提交。比如 ，这样磁盘 I/O 从 10 万次变成 1 次，速度直接起飞。我试过，批量插入 100 万行数据，用事务比不使用快了 20 倍。你想想，这不就是“攒一波再发”的道理吗？
还有一招，很多人不知道：关闭同步模式。SQLite 默认安全第一，每次写操作都强制同步到磁盘，确保数据不丢。但这代价太大，特别是对临时数据或日志场景。可以用 关掉同步。别怕，这不是让数据裸奔——如果你有备份机制，或者数据丢了还能重建，关掉同步能让写入速度飙到极限。我有个朋友做爬虫，用 SQLite 存临时抓取结果，关掉同步后，写入速度从每秒几百条涨到几千条。当然，关键数据别这么干，权衡利弊再操作。
说到性能，还有个容易忽略的点：用 WAL 模式代替默认的回滚日志。默认的 DELETE 模式下，读写互相锁定，多线程并发时性能惨不忍睹。换成 WAL（Write‑Ahead Logging）模式，读和写可以同时进行，冲突少得多。，就这么简单。我做过测试，在并发查询场景下，WAL 模式比默认模式快了 3 倍以上。而且 WAL 的写入也更快，因为它把日志写到单独文件，不用频繁覆盖原数据。不过要注意，WAL 模式下会多出一个 文件，别误删。
索引、事务、同步、日志模式都搞定了，但查询仍然慢，可能是 SQLite 的查询计划器犯了傻。比如，你有个复合索引 ，但 WHERE 条件只用了 ，SQLite 可能会放弃索引，直接全表扫描。这时需要用 看执行计划。我见过一个案例：一个 JOIN 查询，优化前要 5 秒，分析后发现缺了个覆盖索引，加上后直接降到 0.2 秒。做法是 ，让索引覆盖所有查询字段，避免回表。
再说内存调优的技巧。SQLite 默认的缓存大小是 2 MB，这对小库还行，但库大了就捉襟见肘。可以用 把缓存设成 8 MB（负数表示 KB）。更大的缓存意味着更少的磁盘 I/O，查询速度自然提升。我见过一个极端案例：一个 500 MB 的数据库，缓存从 2 MB 调到 64 MB后，全表扫描快了 5 倍。不过别贪心，缓存太大可能影响其他程序的内存使用，具体大小需要根据数据量和系统内存来调试。
还有一个隐藏技巧：定期使用 整理数据库。SQLite 删除数据后不会自动回收空间，而是留下“空洞”，导致文件膨胀、查询变慢。执行 会重建整个数据库文件，压缩空间、优化布局。我见过一个库删掉 50% 数据后没整理，查询反而比原来更慢。跑一次 ，文件从 10 GB 缩到 5 GB，查询速度也恢复如初。但这操作比较重，建议在低峰期执行，或者使用 让 SQLite 自动处理，效果没有手动彻底。
如果要处理大规模数据，SQLite 有个绝招：临时表。把复杂查询的中间结果存到临时表，能省去重复计算。比如，你要统计每个用户的月消费，直接查询可能很慢。可以先把用户 ID 和日期索引一下，然后 。后续查询基于这个临时表，速度提升十倍不是梦。当然，临时表用完记得 ，别占用内存。
说到底，SQLite 不是万能，但用对技巧，它真的能让你眼前一亮。我见过一个初创公司把 SQLite 当生产数据库，配合这些优化，撑住了百万级用户的数据量。别被“嵌入式”三个字吓到，它骨子里就是个强大的关系型数据库。从今天开始，给索引、事务、WAL 模式等点动手，我打包票，你的查询速度会从“忍不了”变成“爽翻”。别忘了，优化是个持续的过程——每次改完都多跑几个测试，找到最适合你场景的平衡点。
