站群数据库分库怎么落地？老站长聊透分库方案选型与实操坑

把站群做到上百个站点之后，数据库这道坎基本人人都得面对。单库单表的内容记录攒到几百万条，后台发文章开始一顿一顿的，前台列表页隔三差五超时，MySQL 写入队列越排越长，这种时候再往上堆索引、加缓存也只是拖延，库结构本身得动一动了。下面拿我经手过的几个站群项目当例子，把数据库分库方案拆开说说。

先判断该不该分，别为了分库而分库

不少同行一见数据库变慢就急着分库，分完十几个库，运维成本翻了几倍，性能却没见涨多少。我自己的判断标准挺土的：单表数据量稳稳超过 500 万行、单库 QPS 峰值长期贴着实例上限、备份窗口拉到两小时以上，这三条里占了两条才值得动手。站群业务有个特点，站点数量多但单站数据量其实不大，真正把库撑爆的往往是汇总表、采集队列表和日志表，先把这几类表拆出去或者做归档，说不定就缓过来了。

分库维度的选择：按站点切还是按业务切

按站点哈希分库

站群里最常见的做法就是这个。拿 site_id 做哈希取模，不同站点分别落到不同库上。好处很直接，站点之间天然隔离，某个站被采集打爆了也只影响自己那个库，不会连累一整片。麻烦在于站点数量会变，取模的基数一改就得做数据迁移，所以我在项目里一般预留库位，比如按 16 个库规划、先启用 4 个，后期扩站直接挪库，不用重算。跨站统计类的需求会变得难受，总后台要看全站汇总，只能走中间层聚合。

按业务模块分库

内容库、用户库、订单库、日志库各走各的实例。站群系统里内容发布和采集写入的压力最大，单独给它一个库，用户和配置类数据放另一个库，互不干扰。这套方案对代码改造要求高，原来的跨表 JOIN 基本得拆成两次查询在应用层拼，早期项目我没有分库中间件，直接在 DAO 层写了一堆拼装逻辑，后来维护起来相当痛苦。

中间件与读写分离的配合

分库之后总得有东西帮你路由 SQL，不然每个业务方法里手写数据源切换，出错率太高。常用的就是 ShardingSphere 这类中间件，配好分片规则，应用层基本无感。读写分离要跟分库一起规划，主库负责写，从库扛列表页和搜索页的读请求，站群前台 PV 高、读多写少，这个比例很好利用。我踩过的坑是主从延迟，采集任务刚入库的内容前台立刻查不到，后来把发布后的即时查询强制走主库，延迟问题才算压下去。

跨库查询和统计的处理

分库以后最烦的就是总后台的汇总报表。我的做法是单独建一个统计库，用定时任务把各分库的关键指标抽过来，报表只查统计库，不碰业务库。实时性要求高的数据走异步消息，写入时顺手发一条到队列，统计侧消费落库。跨库分页查询尽量在业务上规避，站群后台的站点列表按库分组展示，比强行做全局分页省事得多。

扩容与站点迁移的实操细节

站点数量涨上来要加库，迁移时先把目标库建好，用工具做全量同步，再开增量追平，最后切换配置。域名和站点绑定关系存在配置库里，切换时只改分片规则，站点侧无感。迁移窗口我一般选凌晨，提前把采集任务停掉，避免迁移过程中又有新数据写进旧库。另外提醒一句，分库后每套库的账号权限、慢查询监控、备份策略都要单独配，别一套模板复制到底，出问题时排查会很乱。

站群系统数据库分库方案没有标准答案，站点规模、团队运维能力、代码改造空间都会影响选型。我的经验是先做业务拆分和冷热分离，真到单库扛不住再上分库，分的时候优先按站点哈希，配合中间件和读写分离，把跨库统计挪到独立统计库，这套组合在几百站规模的站群里跑得比较稳。