Xiuno论坛数据库深度优化指南：让你的社区访问速度提升10倍

52JinY 助手

折腾xiuno好几年了，数据库这块踩过不少坑，今天把自己的经验整理一下，希望对同样在用xiuno的站长有点参考价值。

先说背景，我的站是个小众技术论坛，注册用户大概两万多，帖子累计十几万条。刚开始那段时间没怎么在意数据库优化，反正访问量也不大，MySQL默认配置跑着也没什么问题。但随着数据量慢慢涨起来，某些页面的加载时间开始变得很难看，尤其是帖子列表页和搜索功能，有时候要等三四秒才出结果，用户体验直接崩了。

后来我开始认真看慢查询日志，发现xiuno本身的查询逻辑其实写得还算规整，但默认情况下bbs_post这张表的索引不够用。帖子表的数据量一旦上去，tid和dateline字段的联合查询就容易产生全表扫描。我给这两个字段加了复合索引之后，帖子列表页的响应时间直接从2秒多降到了200毫秒以内，效果非常明显。所以我的第一个建议是：一定要打开慢查询日志，不要凭感觉猜，要用数据说话。

另一个让我头疼了很久的是session表。xiuno把session信息存在数据库里，如果你的站有一定的并发量，这张表会被频繁读写，非常容易成为瓶颈。我当时的做法是把session存储改到Redis，改动其实并不复杂，主要是对接一下缓存驱动，把原本写数据库的那部分逻辑换掉。切换之后数据库的写入压力明显下来了，效果立竿见影。当然，如果你的服务器内存比较紧张，没条件上Redis，那至少要定期清理过期的session记录，别让这张表无限膨胀。

MySQL的配置文件这边也值得好好调一调，很多人装完就不管了，完全用默认值跑。innodb_buffer_pool_size这个参数非常关键，建议设置为物理内存的50%到70%左右。如果你的服务器有4G内存，可以尝试把这个值设到2G甚至2.5G，把热数据尽量留在内存里，减少磁盘IO。另外query_cache_size这个东西在高并发写入的场景下反而会拖慢速度，MySQL 8.0已经把它彻底移除了，如果你还在用5.7，可以考虑直接关掉query cache，别指望它帮你优化。

表的维护也不能忽视，运行一段时间之后，bbs_post这类高频写入的表会产生碎片，OPTIMIZE TABLE可以整理碎片，但要注意这个操作会锁表，建议放在深夜访问量最低的时候执行，别在白天搞，容易把站搞挂。我一般是设一个每月一次的定时任务，自动跑一遍。

还有一点是关于全文搜索的，xiuno自带的搜索功能依赖数据库的LIKE模糊查询，数据量一大就非常慢，这几乎是没有优化空间的。如果你的站对搜索体验有要求，最好引入Elasticsearch或者Sphinx来做外部搜索索引，把搜索请求从MySQL那边剥离出去。这个改造成本会高一些，但对用户体验的提升是质的飞跃。

总的来说，xiuno的数据库优化没有什么特别神秘的地方，核心思路无非是：合理建索引、减少不必要的数据库读写、把MySQL的内存参数调到合适的值、定期做表维护。按这个方向逐步来，大部分性能问题都是可以解决的。有什么具体问题欢迎在帖子里聊，我看到了都会回。