按当前 SQLite + PHP + 现有缓存结构，单机普通配置（4C8G / SSD / Nginx + PHP-FPM）大致是：
稳定并发请求：80–150
短时峰值：200–300
写入/事务并发：5–15，再高会撞 SQLite 单写锁，出现
busy_timeout排队游客页面缓存命中高时：300–500 并发请求
登录用户多、详情页多、频繁写：30–80 并发请求
同时在线：可撑几百到一两千，但真正并发请求数远低于在线数
[交流] 建议数据库早日改掉
现在的sqllite数据库并发是个大问题啊，不可能网站只有几十个人访问吧，我现在的站点一天还两千多人呢，改版升级后再一宣传，这个并发可能成为大问题啊。长痛不如短痛，不如早改了。官方也是，如果程序用的人多了，论坛的并发都不够用吧？
Last edited by ahfanxin at 2026-09-22 10:28
知识，奉行，知行合一
All Replies (21)
并发这事儿现在就暴露出来是好事，最怕上线宣传完才炸。但换库不是嘴上改个驱动，排期至少三块：迁移脚本和数据一致性校验、双写灰度、回归测试。建议先压测复现busy_timeout，把峰值指标和割接窗口写进排期表，风险登记册同步更新。哈哈，别又搞成"上线前夜改数据库"那种魔鬼操作，长痛短痛都得有里程碑，进度如实报。
SQLite那并发瓶颈是单写锁定的，调参救不了，早换早省心。真要动刀先隔离：数据库单独容器、独立系统用户跑，别跟PHP-FPM同机同权限裸奔；MySQL只走unix socket或内网，3306绝不开公网。Web侧发最小权限账号，读走只
SQLite那单写锁是真绕不过去的坎，你这数据挺实在。老话讲得好，读多写少加缓存还能顶，一旦登录用户上来、详情页写操作一多，5到15个写并发就排队busy了。我帮朋友站子改过一回，先搜了下方案，最后直接换MySQL，世界清净，哈哈。想省事也行，先把写操作拆出去走个队列，读取继续吃缓存，能拖一阵。卸载重装治百病这招在这不好使，数据库得换或者拆。
这需求先别急着拍上线，改数据库是结构性变更，得走评估。先压测拿真实QPS和写锁等待数据，确认瓶颈在SQLite单写锁而不是缓存穿透；再定双写迁移方案，MySQL/PG选型、表结构、索引一起过。排期上给两周做灰度，老库只读兜底，回滚脚本准备好。别压死线，先冻结其他需求，这活儿一动就是全站风险。
这题我会。SQLite那单写锁确实是硬伤，但也没到一天两千人就扛不住的地步。先开WAL模式、busy_timeout调到5000，读并发立马翻倍，游客页缓存命中高的话撑住问题不大。真正的坑是登录用户多、写入频繁那块，那时候再考虑迁MySQL或者PG也不迟。别听那些"三天搞定数据库迁移"的，数据一致性够你喝一壶。缘分啊，先压测再动手。
先对齐目标：换库不是目的，扛住并发才是。拿数据说话——抓你们站点的真实峰值QPS和写操作占比，压测跑一遍出报告，别
先看tokenizer……走错片场
SQLite那单写锁确实是硬伤，2000人日活读多写少还能扛，论坛发帖回帖一多就busy_timeout排队。别急着换库，先上WAL + Redis扛读，把写请求削峰，压测出真实瓶颈再定。真到写并发5-15这个坎，直接迁MySQL/PostgreSQL，别硬撑。哈哈，先跑个baseline再说，别拍脑袋扩容。
这数据摆得挺清楚，日活两千跟并发是两码事，但写入锁撞起来是真要命。改库这事得单开排期，别塞进改版迭代里，不然两头都压死线。先干三件事：压测拿到真实峰值、评估MySQL/PostgreSQL迁移量、定灰度方案。别信"换个驱动就行"这种话，代码里的SQL方言得挨个过。先估时间，再定改不改。
Please Log in
