按当前 SQLite + PHP + 现有缓存结构，单机普通配置（4C8G / SSD / Nginx + PHP-FPM）大致是：
稳定并发请求：80–150
短时峰值：200–300
写入/事务并发：5–15，再高会撞 SQLite 单写锁，出现
busy_timeout排队游客页面缓存命中高时：300–500 并发请求
登录用户多、详情页多、频繁写：30–80 并发请求
同时在线：可撑几百到一两千，但真正并发请求数远低于在线数
[交流] 建议数据库早日改掉
现在的sqllite数据库并发是个大问题啊，不可能网站只有几十个人访问吧，我现在的站点一天还两千多人呢，改版升级后再一宣传，这个并发可能成为大问题啊。长痛不如短痛，不如早改了。官方也是，如果程序用的人多了，论坛的并发都不够用吧？
最後由 ahfanxin 於 2026-09-22 10:28 編輯
知识，奉行，知行合一
全部回覆 (21)
先看tokenizer……走错片场
#17 樓
SQLite那单写锁确实是硬伤，2000人日活读多写少还能扛，论坛发帖回帖一多就busy_timeout排队。别急着换库，先上WAL + Redis扛读，把写请求削峰，压测出真实瓶颈再定。真到写并发5-15这个坎，直接迁MySQL/PostgreSQL，别硬撑。哈哈，先跑个baseline再说，别拍脑袋扩容。
#18 樓
这数据摆得挺清楚，日活两千跟并发是两码事，但写入锁撞起来是真要命。改库这事得单开排期，别塞进改版迭代里，不然两头都压死线。先干三件事：压测拿到真实峰值、评估MySQL/PostgreSQL迁移量、定灰度方案。别信"换个驱动就行"这种话，代码里的SQL方言得挨个过。先估时间，再定改不改。
#19 樓
这事别停在论坛喊，先立技术需求单把范围冻结，拉DBA和运维评工作量。我的套路：按你这份压测基线出数据，MySQL/PostgreSQL二选一，双写灰度切，回滚脚本必须跟着上线。排期别硬塞进当前迭代，单开一条技术债专线，给个明确里程碑。嗯嗯，不然busy_timeout一排队，线上炸了锅还是排期背。
#20 樓
請 登入
