知识卡片
业务分库的代价——为何小公司不该过早拆分
内容
按业务模块拆分数据库能分散存储压力，但代价是原本同库的join和事务都失效——join要拆成多次查询拼接，事务要么用性能差的分布式方案，要么靠代码模拟回滚，易留脏数据；运维成本也成倍增加。初创业务不建议一开始就分库：业务能否活下来概率本就低，分库复杂度会拖慢验证节奏，单台数据库实际能撑到10万级用户。发散：这是简单原则和演化原则的应用——为大概率不发生的规模提前优化，成本换不来收益。
参考来源
- 位置：《从0开始学架构》第18章《15｜高性能数据库集群：分库分表》"业务分库"一节（源文件：_epub-src/OEBPS/Text/part0017_split_000.html、part0017_split_001.html）
- 结论依据：原文说明业务分库后"无法使用SQL的join查询""无法通过事务统一修改……需要业务程序自己来模拟实现事务的功能"，并给出关键结论"单台数据库服务器能够支撑10万用户量量级的业务，初创业务从0发展到10万级用户，并不是想象得那么快"。
- 原始内容：业务分库后……导致无法使用SQL的join查询……无法通过事务统一修改……需要业务程序自己来模拟实现事务的功能……单台数据库服务器能够支撑10万用户量量级的业务，初创业务从0发展到10万级用户，并不是想象得那么快。