业务分库的适用时机：初创公司宜迟，大公司新业务宜早

面对[[业务分库分散存储压力，但引入join、事务与成本三重代价]]带来的复杂性，是否要一开始就做业务分库，答案要按公司/业务所处的阶段分情况判断，而不是有统一标准。对小公司的初创业务，不建议一开始就做业务分库，理由有三层：初创业务本身存在很大不确定性，大部分业务根本发展不起来，业务早期通常也谈不上真正的存储和访问压力，业务分库这时候创造不出实际价值；业务分库会立刻引入join查询和事务实现上的复杂性；而且分库后代码里要新增”数据类型到具体数据库”的映射逻辑，增加的这部分工作量恰恰会拖慢初创阶段最需要的”快速实现、快速验证”节奏。有人会问：如果业务真的发展很快，岂不是很快又要被迫做业务分库，那为什么不从一开始就设计好？用架构设计三原则可以直接回答这个疑虑：其一，”业务真的发展很快”这个”如果”本身发生概率就很低，十个业务里能活下来一个已经不错，快速爆发式增长的概率和中彩票差不多，如果每个业务从第一天就按淘宝、微信的规模去设计架构，只会把团队自己拖垮、还耽误业务本身；其二，即便真的发展很快，事后再做业务分库也不迟——业务发展好意味着能投入的人和钱也在同步增加，分库带来的代码复杂度问题可以用增加的人力去消化，成本问题也可以用增加的资金去覆盖；其三，单台数据库服务器的性能其实没有想象中那么弱，一般能支撑到10万用户量级的业务规模，而初创业务从0发展到10万用户，通常没有想象中那么快。但对业界成熟的大公司来说，情况本质不同——它们已经有了业务分库的成熟解决方案，而且即便是尝试性的新业务，起步用户规模也往往是海量的，因此这类新业务最好在设计之初就把业务分库、甚至更进一步的分表方案一并考虑进去。

结构图：

flowchart TB
  A["业务分库的适用时机"]
  A --> B["小公司初创业务：不建议一开始就做"]
  B --> B1["理由①业务不确定性高，多数活不下去<br/>早期通常没有真实存储压力"]
  B --> B2["理由②join/事务复杂度立刻上升"]
  B --> B3["理由③增加映射逻辑工作量<br/>拖慢初创期最需要的快速验证节奏"]
  B1 --> C["三原则回应'万一发展很快怎么办'"]
  C --> C1["快速爆发概率极低，不该按淘宝规模设计"]
  C --> C2["真发展快，事后分库不迟，人和钱会同步跟上"]
  C --> C3["单机性能没那么弱，一般能扛到10万用户量级"]
  A --> D["大公司新业务：建议一开始就做"]
  D --> D1["已有成熟分库解决方案"]
  D --> D2["即使是尝试性新业务，起步用户规模也往往海量"]