Xiuno 高并发实战：数据库分库分表与读写分离架构设计思路全解析

52JinY 助手

最近在折腾 Xiuno BBS 的性能优化，论坛规模一上来，数据库就开始喘不过气了。帖子量过百万之后，post 表查询明显拖慢，后台偶尔还会出现超时报错。趁着这段时间系统性地研究了一下分库分表和读写分离的思路，在这里跟大家聊聊，算是个阶段性总结，也欢迎有经验的朋友一起讨论。

首先说说为什么 Xiuno 在高并发场景下容易出问题。Xiuno 的数据库结构设计其实比较简洁，主要的压力集中在 bbs_post、bbs_thread 这几张核心表上。读操作远多于写操作，但偏偏很多查询还带着复杂的 JOIN 和排序，一旦并发上来，锁竞争和慢查询就同时出现了。最开始我以为加索引就够了，后来发现根本治标不治本，数据量涨到一定程度之后，再好的索引也挡不住全表级别的压力。

读写分离是第一步要做的事情，成本相对低，收益却比较明显。基本思路是搭一主多从的 MySQL 架构，主库只负责写入，从库承担所有读请求。Xiuno 的底层用的是 PDO，理论上可以在数据库连接层做一层代理封装，根据 SQL 类型自动路由到主库或从库。我的做法是直接改了 db.php 这个核心文件，加了一个简单的判断逻辑，SELECT 走从库连接池，INSERT/UPDATE/DELETE 走主库。实际跑下来，从库分担了大约七八成的查询压力，主库的负载下降非常明显。当然，主从延迟是个需要注意的地方，对实时性要求高的场景，比如用户刚发完帖子立刻跳转帖子页，这时候要强制走主库读，避免出现"发了帖子刷新看不到"的尴尬情况。

分表这块要复杂一些，需要结合实际业务场景来设计。bbs_post 是最需要拆分的表，按照 tid（主题 ID）取模做水平分表是一个思路，比如拆成 post_0 到 post_15 共 16 张表，每次操作根据 tid % 16 决定走哪张表。好处是单表数据量直接压下来，查询速度肉眼可见地快。坏处也很明显，跨表聚合查询几乎没法做，统计类功能要另外想办法。我目前的处理方式是把需要统计的数据单独用 Redis 缓存维护，定期异步同步，不依赖直接的 SQL 聚合。

分库则是更大动作，适合规模已经很大的站点。把不同的业务模块放到不同的数据库实例上，比如用户数据、帖子数据、消息数据各走各的库，减少单实例的连接压力。Xiuno 本身的模块化设计还算清晰，改造起来并不是完全没有入手点，但工作量确实不小，特别是跨库事务这个问题要提前想清楚处理策略。

最后说一点个人感受：分库分表不是银弹，盲目拆分反而会引入更多的维护复杂度和潜在 bug。建议在真正遇到性能瓶颈之前，先把缓存层做好，Redis 缓存热点帖子列表、用户信息这些高频读取数据，往往能解决大部分问题。等到缓存也撑不住了，再考虑读写分离，最后才是分表分库。按这个优先级来，每一步都踩在实际需求上，不会做无用功。

如果你的 Xiuno 站点已经开始出现明显的数据库卡顿，欢迎留言聊具体情况，也许能一起找到更合适的方案。