Discuz论坛性能飞跃：数据库查询优化实战技巧全解析

52JinY 助手

最近帮朋友维护一个用Discuz跑了七八年的老论坛，数据库里光帖子表就有两千万条记录，每次打开版块首页都要转好几秒，查询超时更是家常便饭。折腾了将近一个月，总算把响应时间压下来了，趁这个机会把一些实际用到的优化思路整理出来，希望对同样在维护大论坛的朋友有点参考价值。

先说最基础也最容易忽视的一点——索引。Discuz默认建的索引其实够用，但随着数据量增长，很多复合查询会绕开这些索引。建议用EXPLAIN命令逐条分析慢查询日志里出现频率最高的SQL语句，很多时候你会发现一条看起来简单的帖子列表查询，底层居然在做全表扫描。我当时发现pre_forum_post这张表上，针对tid和dateline的联合查询完全没有走索引，手动加了一个复合索引之后，相关页面加载时间直接砍掉了一大半。

慢查询日志一定要开。在my.cnf里把slow_query_log打开，long_query_time设置成1秒，跑个几天，你会看到哪些查询是真正的"老赖"。Discuz有一些历史遗留的查询写法不太高效，比如某些涉及GROUP BY又没有良好索引支撑的统计操作，这类查询在高并发时会直接把数据库CPU拉满。找出来之后可以考虑把统计结果缓存起来，不需要每次都实时计算。

说到缓存，Discuz自带的数据缓存机制用好了能顶大用。建议把Memcached或者Redis接进来，论坛的版块信息、用户组权限、积分规则这些几乎不变的数据完全可以缓存住，没必要每次请求都去查库。另外论坛首页的"最新帖子""热门话题"这类聚合数据，也可以用定时任务定期刷新缓存，而不是靠实时查询撑着。

表分区是另一个值得尝试的方向。帖子表、附件表这类数据量巨大且以时间顺序写入的表，按年或按月做RANGE分区之后，历史数据的查询范围会明显缩小，MySQL可以直接跳过不相关的分区。不过这个操作需要对现有表结构做改动，上生产环境之前一定要备份，而且要评估一下分区键和现有查询条件是否匹配，否则分区了也白分区。

连接池这块很多人没注意。Discuz的数据库连接是按请求建立和释放的，高并发时频繁的连接创建本身就是开销。如果你的服务器环境支持，可以在前面挂一个ProxySQL或者用PHP-FPM配合持久连接来缓解这个问题。当然这个方案有自己的坑，持久连接管理不好会出现连接泄漏，需要配合监控使用。

最后想说的是，优化是个持续的过程，不是一次性的事情。数据量在涨，访问模式也在变，今天优化好的查询，半年后可能又变慢了。养成定期看慢查询日志的习惯，比任何一次性的优化操作都重要。有条件的话搭一套监控体系，把数据库的QPS、慢查询数量、锁等待时间这些指标都纳入监控，出问题之前就能预警，比等用户来反馈"网站好慢"要主动得多。

有遇到类似问题的朋友欢迎留言交流，论坛运维这条路，大家多分享才能少踩坑。