Sharding之前先问"是否真的需要"：避免过早分片和过度拆分的双重陷阱

在讨论分库分表（Sharding）方案之前，原文先引用了一句业界广泛认同的告诫：”Sharding非常复杂，除非确实明显需要，否则最好不要分片”（Sharding is very complex, so it’s best not to shard until it’s obvious that you will actually need to）。这句话提醒的是一种常见的过早优化倾向：分片本身是为了解决单机写入压力过大和容量瓶颈这类真实存在的问题，但分片一旦实施，会带来数据分布规则、跨分片查询、分布式事务、运维复杂度全面上升等一系列新的复杂性——如果业务实际上还没有真正遇到单机瓶颈，就提前引入分片架构，等于是在没有收益的情况下提前背上了这些复杂性负担。文中”单表60亿记录、单表容量1.2TB”这个真实案例恰恰是这条原则的一个极端印证：这张表按照文中自己制定的开发规范（单表数据量控制在1亿以下）本该早就拆分，但实际上一直没拆，原因排在第一位的是”性能未遇到瓶颈”——正是因为分片带来的复杂性收益不明显，团队才选择继续在单表规模下想办法优化（最终用切换存储引擎解决了核心痛点），而不是贸然引入分片架构。原文同时也提醒了另一个方向的陷阱：一旦真的需要分片，也要”拆分要适度，切勿过度拆分”，理想情况下应该有一个中间层来统一控制拆分逻辑，因为拆分得过细同样会造成管理成本急剧上升。这两条建议共同构成了一条关于”要不要引入某种应对规模增长的复杂架构手段”的判断标准：不要因为”担心未来可能会有瓶颈”就提前引入复杂方案，要等瓶颈真实、明确地出现之后再采取行动；一旦真的要采取行动，也要控制好复杂方案本身的粒度，不要矫枉过正地过度使用它。