数据库读写分离与缓存加速部署

学完这篇，你能判断自己的 Clara BBS 论坛到底该不该上读写分离，以及在不改一行代码的前提下把缓存加速做到位。

第一步：先分清两件事，别一上来就搞主从

读写分离解决的是"读请求压垮数据库"，缓存解决的是"同一个数据被反复查/反复算"。Clara BBS 是 PHP 7.4-8.5 + MySQL 5.7+ 的轻量论坛，无 Composer、无命令行、无编译缓存，系统本身按单库读写设计，后台没有"读写分离"开关。

所以先记住一句：读写分离是数据库层/服务器层的工程手段，不是系统功能；缓存加速才是你该先做的事。

注意：绝大多数中小社区的性能问题不是"读扛不住"，而是重复查询和没必要的实时计算。先上缓存，再谈主从。

第二步：把系统自带的缓存机制用起来

Clara BBS 的插件公共设施里有 `Cache::remember`，插件开发时用它包住耗时的查询或计算，命中缓存就直接返回，不用每次重跑。

后台「系统工具 → 缓存清理」是出问题时的兜底入口，平时不用手贱去点。系统本身是"保存即生效、无需清缓存"的设计，改配置、装插件都不需要清缓存。

注意：`Cache::remember` 是给写插件的人用的 API，不是让你去改核心文件。要加缓存逻辑，写在插件里。

第三步：PHP 与 MySQL 侧的基础加速

这两项属于服务器层面，跟系统无关，但对轻量论坛收益最直接。

PHP 侧打开 OPcache：PHP 7.4+ 自带，宝塔面板在「软件商店 → PHP → 设置 → 性能调整」里开启，脚本不用每次重新编译。

MySQL 侧三件事：

1. 开慢查询日志，先看谁慢，再动手优化；
2. 按慢查询结果针对性加索引，别凭感觉给所有字段加；
3. 宝塔「数据库 → 性能调整」调大 `innodb_buffer_pool_size`，内存够就调到物理内存的 50%~70%。

注意：加索引要谨慎，Clara BBS 表结构自带索引，乱加会拖慢写入。只加慢查询日志里明确出现的那几条。

第四步：真要做读写分离的通用路线

如果日志显示读请求确实把 MySQL 打满了，走这条路：

1. 搭 MySQL 主从复制（binlog，服务器层面操作）；
2. 在连接层部署代理，比如 ProxySQL 或 MySQL Router，由它把读分流到从库、写留在主库；
3. 系统侧唯一要改的，是把数据库连接地址指向代理而不是直连主库——填在安装向导或配置文件的数据库信息里。

就这么简单，系统不需要感知主从。

注意：主从延迟是论坛的致命伤。发帖跳转、回帖、点赞、私信这类"写完立刻读"的请求，必须在代理里配规则强制走主库，否则用户发完帖刷新看不到，会以为发失败了。

注意：钱相关的操作绝对不许读从库。悬赏发布即从余额托管冻结、悬赏采纳后发放、多货币转账、卡密兑换、附件交易、礼物打赏，全部走统一记账。读到旧余额就等于出事故，这些 SQL 在主从规则里必须锁死走主库。

注意：读写分离不解决文件和会话问题。uploads 目录和 session 不在数据库里，多机部署必须做共享存储和共享 session，否则图片时有时无、登录状态乱跳。

第五步：什么情况下别折腾

单机 MySQL + OPcache + 合理的 `innodb_buffer_pool_size` + 插件里用 `Cache::remember`，这套组合能扛的量远超你想象的多数场景。读写分离会引入主从延迟、数据一致性、运维复杂度三份额外成本，没有实测瓶颈之前不要上。

先开慢查询日志，看两周数据，再决定。

小结

• Clara BBS 是单库架构，系统不提供读写分离开关，主从属于服务器层
• 加速顺序：OPcache → MySQL 缓冲池与慢查询 → 插件内 `Cache::remember` → 最后才考虑主从
• 做读写分离时，写后立读的请求（发帖、回帖、点赞）必须强制走主库
• 所有涉及余额、悬赏托管、交易记账的 SQL 一律走主库，绝不能读从库
• 多机部署必须解决 uploads 目录与会话共享，读写分离不管这个