SQLite 快撑不住时，会先出现这几条
把 SQLite 用到瓶颈的过程不是突然崩掉，是一点点变难受。SQLite 性能到瓶颈有哪些信号，我整理了五条自己会盯的现象，出现两条以上就该认真考虑换数据库，出现一条先优化。
一、写入开始排队，而不是变慢
信号是写入的耗时忽长忽短，平均值看着还行，但偶尔冒出很高的一个。
原因是写锁只有一个，谁来晚了就得等。排队和变慢是两回事：变慢可以通过优化改善，排队只能通过减少写入者或者换数据库解决。
具体动作：把每次写操作的耗时记下来，看的是最大值和分布，不是平均值。
二、报锁的频率在上升
信号是 database is locked 从偶发变成日常。
短时间的锁冲突本来正常，频率明显上去说明并发已经超出它能吸收的范围。这时候先确认自己的写操作有没有收拢，收拢了还这样就是真到量了。
具体动作：按天统计报锁次数，看趋势。趋势比单日数字重要。
三、读也开始受写的影响
信号是明明查的是只读接口，响应时间却跟着写入高峰一起波动。
读被写挡住，说明写事务持有时间太长，或者日志模式的设置让读写互斥得更厉害。先查有没有长事务，再考虑调整模式。
具体动作：找出执行时间最长的那几条查询和事务，逐条看它们在做什么。
四、事务越写越短，还是压不住
信号是你为了减少冲突，把事务拆得越来越碎，效果却越来越差。
这说明冲突的根源不是事务边界，是写入总量已经超过单个写入者的处理能力。继续拆事务只会让每条写入都多付一次提交成本。
具体动作：统计单位时间内的写入条数，跟你的业务增长对一下。
五、备份窗口和磁盘开始变成约束
这一类信号不是代码问题，是运维问题，出现得最晚但最难绕过。
备份的信号是你得挑一个没人的时间点去复制数据库文件，白天不敢动。备份需要停顿这件事，在小数据量时感觉不到，量上去以后会变成硬约束。
磁盘的信号是开始有人问你磁盘还剩多少、写入速度够不够。数据库文件跟服务抢同一块磁盘，小规模时无所谓，量上来会互相拖累。
具体动作：写下你现在备份一次需要多长、文件现在多大，再估一下多久需要处理一次。
六、SQLite 性能到瓶颈有哪些信号：先做哪个
五条信号里，第一和第二条最值得盯，它们最早出现、最容易量化。第三和第四条是补救信号，出现了说明你已经拖了一段时间。
第五条不用主动盯，它是前面积累的结果。你真正要做的是在前两条出现时就想清楚：是优化写法，还是准备迁移。
判断标准我给自己定的是：报锁频率按周在涨，就停止优化，开始评估迁移。继续在代码上抠，收益会越来越小。
还有个前提要说清楚：这些信号的前提是你已经做过了基本优化。写操作收拢、事务合并、忙等超时设上，这三件事没做之前，看到的「瓶颈」很可能是自己代码造成的，不是数据库的极限。
所以顺序是先自查，再判断。别拿没优化过的状态去给数据库定罪。
常见问题
Q：SQLite 到瓶颈一定要换成 MySQL 吗？
A：不一定。如果瓶颈只是写入排队，先把写操作收拢、把事务合并，可能就够了。换库是当这些手段都压不住时的选择。
Q：数据量多大算撑不住？
A：没有一个通用数字，跟行大小、索引、查询方式都有关系。别拿一个别人的数字做决策，看你自己的报锁频率和写入耗时。
Q：迁移前需要做哪些准备？
A：先把数据访问收拢到一个接口层，再确认有没有用到某一家的专有语法。这两件事做完，迁移的代价就从「重写」变成「换实现」。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」