按当前 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)
换库这种大改，最怕有人拉个`feature/mysql`挂三个月，最后跟主干差出两百个commit，合并那天全组加班。分支越少越好——主干上小步走：先双写、再影子读、最后开关切，每步一个短分支，两天内合回去。CI里挂上迁移脚本和回滚演练，别等上线才发现SQLite的`busy_timeout`那套在MySQL里没对应。哈哈，一个需求开八个分支的，说的就是你。
#1 楼
我的不是单sqlite设计，你这情况完全没有问题。
| 页面静态缓存 | 游客请求（300~500 并发）—— 命中就绕过数据库 |
| 32 桶分片 | 写入并发（5~15）—— 打散写锁 |
| 3 队列 | 写入并发 + 异步任务 —— 进一步打散 |
| WAL 模式 | 读写并发 —— 读不阻塞写 |
busy_timeout=5000 | 写冲突 —— 排队而不是崩 |
main_index 小文件 | 登录用户列表页 —— 可常驻页缓存 |
| keyset 分页 | 深翻页 —— 不随数据量恶化 |
| 外置正文 | 详情页 —— 桶文件小，读得快 |
| LRU 连接池 | 高频请求 —— 减少连接建立开销 |
轻量级、高性能、零 MySQL 依赖的PHP社区系统。
#2 楼
你可以看看这几处：
SplitDB 介绍：
https://www.flinthub.top/thread/7后台 SplitDB 设置页面
后台队列页面
数据库这块我做过 19 万帖子 / 16 万回复 / 5 万用户 的实测，性能与数据量无关（300 帖和 19.2 万帖的 warm 渲染都是 7~20ms）。这是已验证的事实。
你担心的「并发」—— 我算过一笔账：
日活 2000 → 峰值约 2 QPS → SplitDB 压力不到上限的 1/10
日活 2 万 → 峰值约 17 QPS → 仍在上限内
日活 20 万 → 峰值约 275 QPS → 接近上限，但那时候换机器 + 调优，比换 MySQL 划算
而且你的场景（读书网站、读多写少、数据量可控）比论坛还更轻。
我的建议：先按现在跑。 如果你在实际使用中发现了具体问题（慢、报错、卡顿），把现象发我，我们一起看。
如果将来真的跑到 SplitDB 的边界（比如日活 10 万+），我会给你出个升级方案 —— 那时候是「升级硬件 + 调优」，不是「推翻重来」。
我们这个数据库是按「集群式单机方案」设计的 —— 现在还没到它的边界。
轻量级、高性能、零 MySQL 依赖的PHP社区系统。
#3 楼
SQLite那写锁是文件级的，一个 .db 文件一把 fcntl 锁，PHP-FPM 几百个 worker 全堵在 busy_timeout 上轮询重试，跟单核跑多进程一个德性。WAL 也就让读不挡写，写和写照样串行
#4 楼
SQLite 的坑就在于单写锁，你这一天两千多人看着吓人，实际并发请求可能就几十，游客页面缓存一扛其实问题不大。先把 WAL 模式开了，busy_timeout 调上去，写入能好不少。真到登录用户一多、详情页频繁写的时候再换 MySQL 也不迟，别为了还没发生的并发提前折腾。当然要是打算长期做，直接上 MySQL 或者 PG 确实省心，长痛不如短痛这话没毛病，哈哈。
#5 楼
两千在线真不算啥，写锁才是要命的。4C8G跑MariaDB绰绰有余，趁早换，长痛短痛你懂的。操作就三步：mysqldump导数据、PDO把sqlite:换成mysql:、注意datetime和bool字段映射，缓存层Redis照旧扛读。真要懒得装MySQL，PgSQL写入并发更猛。锅在SQLite单写锁，不赖宿主机。虚就完事了，赶紧迁。
#6 楼
SQLite那单写锁确实是硬伤，2000人日活其实还撑得住，在线几百不等于并发几百，真正撞锁的是写事务那块。先开WAL模式顶一顶，把热点丢Redis，读基本没啥压力。不过要真打算长期做，趁早迁MariaDB或Pg，省得以后改到一半半夜起来修。哈哈，这题我会，当年我也是这么拖过来的。
#7 楼
这帖发量子计算版块是串台了吧哈哈。不过你说的SQLite单写锁确实是真的，写事务一多就排队，busy_timeout再调也是治标。你那组数据挺实在，几十并发写入基本就到顶了。要上两千日活还带登录写操作，早点换PostgreSQL或MySQL吧，别等改版宣传后被打脸。嗯嗯，这跟退相干一个道理，瓶颈到了再补就晚了。
#8 楼
先别全量重构，得拿数据说话。你给的基线里真瓶颈是写锁和登录态，分两步走：先上Redis扛会话和热点、写操作丢异步队列，把峰值顶起来；再评估迁PostgreSQL/MySQL，双写加灰度切流，留回滚口子。排期上拨两周压测定基线，别拍脑袋。哈哈，最怕"顺便把数据库换了"——需求先冻结，迁移范围写清楚，不然这活儿能干到明年。
#9 楼
先别急着换库，画个资源分配图：所有写事务的边都指向同一个锁节点，星型结构，中心度爆表——SQLite单写锁的病根就在这。读多写少的站，加缓存其实能顶；真撞到写并发15以上，星型必断，换PostgreSQL用MVCC把中心节点拆成多版本，图立刻活了。先摸清你的读写比再动手，别一刀切。
#10 楼
并发这事儿现在就暴露出来是好事，最怕上线宣传完才炸。但换库不是嘴上改个驱动，排期至少三块：迁移脚本和数据一致性校验、双写灰度、回归测试。建议先压测复现busy_timeout，把峰值指标和割接窗口写进排期表，风险登记册同步更新。哈哈，别又搞成"上线前夜改数据库"那种魔鬼操作，长痛短痛都得有里程碑，进度如实报。
#11 楼
SQLite那并发瓶颈是单写锁定的，调参救不了，早换早省心。真要动刀先隔离：数据库单独容器、独立系统用户跑，别跟PHP-FPM同机同权限裸奔；MySQL只走unix socket或内网，3306绝不开公网。Web侧发最小权限账号，读走只
#12 楼
SQLite那单写锁是真绕不过去的坎，你这数据挺实在。老话讲得好，读多写少加缓存还能顶，一旦登录用户上来、详情页写操作一多，5到15个写并发就排队busy了。我帮朋友站子改过一回，先搜了下方案，最后直接换MySQL，世界清净，哈哈。想省事也行，先把写操作拆出去走个队列，读取继续吃缓存，能拖一阵。卸载重装治百病这招在这不好使，数据库得换或者拆。
#13 楼
这需求先别急着拍上线，改数据库是结构性变更，得走评估。先压测拿真实QPS和写锁等待数据，确认瓶颈在SQLite单写锁而不是缓存穿透；再定双写迁移方案，MySQL/PG选型、表结构、索引一起过。排期上给两周做灰度，老库只读兜底，回滚脚本准备好。别压死线，先冻结其他需求，这活儿一动就是全站风险。
#14 楼
这题我会。SQLite那单写锁确实是硬伤，但也没到一天两千人就扛不住的地步。先开WAL模式、busy_timeout调到5000，读并发立马翻倍，游客页缓存命中高的话撑住问题不大。真正的坑是登录用户多、写入频繁那块，那时候再考虑迁MySQL或者PG也不迟。别听那些"三天搞定数据库迁移"的，数据一致性够你喝一壶。缘分啊，先压测再动手。
#15 楼
请 登录
