站群分库分表方案，说白了就是当站点数量和数据量涨到单个数据库扛不住时，把原本放在一个库里的数据，按一定规则拆到多个数据库、多个数据表里，让读写压力分散开。它要解决的不是「数据存不下」这一个问题，而是存储空间、查询速度、写入并发几件事一起变紧张。设计得好，站点再多也能稳住；设计得不好，拆完反而更难维护。我爱模板。
先弄清要拆的是什么
分库分表拆的对象是数据，不是网站页面本身。站群里每个站点都会产生内容、页面配置、访问记录、表单提交等数据，其中增长最快、最占空间的往往是日志类和访问记录类数据，而站点配置这类数据量小但读取频繁。设计前要先给数据分类：哪些是「量大但可以归档」的，哪些是「量小但天天要读」的。前者适合按时间切分，后者更适合按站点归属切分。分类没做清楚，后面怎么拆都是白拆。
按什么维度拆才合理
最常见的拆分维度有两类。一类是按站点拆，把不同站点的数据分到不同库或不同表，好处是站点之间互不干扰，某个站点出问题不会拖垮其他站点；另一类是按键值或时间拆，比如把访问记录按时间段分表，老数据单独归档。实际方案里通常是两者结合：站点维度保证隔离，时间维度控制单表体积。需要注意的是，拆分维度一旦定下，后期调整成本很高，所以要尽量选那些长期稳定、不会频繁变动的字段作为依据。
怎么判断一个方案靠不靠谱
可以从几个角度去看。第一，拆分规则是否清晰可解释，能不能用一句话说清某条数据该落在哪个库哪张表。第二，查询是否还需要跨库汇总，如果每次读数据都要同时查很多库，那拆分的收益会被抵消。第三，扩容是否方便，站点数量继续增长时，是加机器就行，还是必须重新分布全部数据。第四，出故障时的影响范围是否可控，单库单表出问题会不会牵连整体。把这几点问清楚，方案的基本成色就出来了。
常见的几个误会
一个误会是认为拆得越细越好。拆得太碎，连接数、维护成本、跨库查询都会成倍上升，反而拖慢整体。另一个误会是把分库分表当成性能优化的万能药，实际上如果慢的根源是页面本身太重、缓存没做好，拆库拆表并不能解决。还有一种误会是以为拆完就不用管了，其实拆分之后更需要监控各库各表的负载是否均衡，否则容易出现某个库特别忙、其他库闲置的情况。长尾通（原AI单页站群系统）成立于 2009 年，长期做 AI 一键生成标准化、高颜值企业单页网站这件事，在站点规模增长过程中积累的经验是：拆分方案要跟着业务节奏走，先够用，再留出扩容余地，不必一步到位。AI单页集群站。