复制集解决了「单点故障」，但没解决「单机装不下」。一台服务器的内存、磁盘、CPU 都有物理上限，当数据量或负载超过单机承受能力，加内存换 CPU 的边际效益越来越低，最终撞上物理天花板。这时候唯一的出路是分片（sharding）——把数据分散到多个节点，让集群整体能力超过任何单机。
这一阶段（24–30）围绕分片集群展开。但开篇要先把一个关键认知摆正：分片不是「让 MongoDB 更好」的功能，而是单机到顶后的无奈手段。它带来巨大的架构复杂度和运维成本，能不用就不用。这一篇讲清楚分片存在的理由，以及什么时候真的该上它。
先把机制边界说清楚
数据库扩容有两种方向：
- 垂直扩容（Scale Up）：单机加内存、换更大磁盘、升级 CPU。简单，不用改架构，但有物理上限，且大配置服务器成本极高。
- 水平扩容（Scale Out / 分片）：把数据分散到多个节点，每个节点存一部分。近线性扩展，但架构复杂。
MongoDB 的复制集本质还是「数据在多台机器上各有完整副本」，单台的数据量没减少——三节点复制集，每台都存全量数据。所以复制集解决高可用，不解决容量。容量问题要靠分片：分片后，每个 shard（分片）只存一部分数据，单台的数据量减少了。
垂直扩容的天花板
垂直扩容到顶有几个硬限制：
内存上限。单台服务器内存几百 GB 到 TB 级就到顶了（再大要么没有这种规格，要么贵到离谱）。工作集超过这个上限，加内存就无效了。
成本边际递减。内存从 64GB 加到 256GB 还算合理，从 256GB 加到 1TB 成本可能是前者的好几倍，性价比急剧下降。
单点风险随规模上升。单机存的数据越多，它故障的影响越大。虽然复制集能容灾，但单机故障后的恢复（全量初始化）时间也越长。
分片怎么解决问题
分片把数据按某个键（片键）分散到多个 shard，每个 shard 是一个独立的复制集（本身有高可用）。这样：
- 容量分散：1TB 数据分到 4 个 shard，每个 shard 只存 256GB，单机内存装得下工作集。
- 负载分散：写入和查询分散到多个 shard，单 shard 的负载降低。
- 近线性扩展：加 shard 就能扩容，理论上没有上限（实际受片键和跨片查询限制）。
代价是架构复杂度大增，这是接下来几篇要展开的：要引入 mongos（路由）、config server（元数据）、设计片键、处理块迁移、应对跨片查询。分片集群的运维复杂度是复制集的数倍。
什么时候真的该上分片
这是最关键的判断——大多数业务根本不需要分片。上分片前，先问这几个「更便宜的替代方案」能不能解决问题：
- 加内存：工作集超过内存，加内存是最简单的解法。只要单机还能装下，就别分片。
- 优化查询和索引：很多「性能不够」其实是索引没建对、查询没优化，不是容量问题。先把索引和查询优化做到位（阶段二的内容）。
- 冷热分离：把冷数据归档到单独的集合或实例，让热集合的工作集变小。这通常能争取很多时间。
只有这些手段都用尽，仍然撞上下面三个瓶颈之一，才该考虑分片：
容量瓶颈：工作集持续增长，单机加内存到顶仍装不下。这是最硬性的分片理由。
负载瓶颈：写入 QPS 高到单机扛不住（比如 IoT 海量设备上报、日志收集）。单机的 CPU 和 IO 成了天花板。
存储瓶颈：数据量超过单机磁盘容量，或单机存储成本不合理。
分片的不可逆性
分片有一个特殊性质让它的决策格外慎重：片键一旦选定，极难更改。改片键要重新分布所有数据，是个巨大且危险的工程（虽然新版有 reshardCollection，但仍是大操作）。片键选错，可能导致数据倾斜、热点、查询全广播，且很难回头。
所以分片决策不是「先上了再说」，而是「确信需要，且仔细设计片键」后再上。片键设计是整个分片阶段的核心，第 26 篇会专门展开。
判断框架
- 分片是单机到顶后的手段，不是常规优化手段。
- 先穷尽更便宜的方案：加内存、优化查询索引、冷热分离。
- 三个真正的分片理由：工作集超内存（容量）、QPS 扛不住（负载）、存储到顶。
- 复制集能解决高可用，分片解决容量和负载，不要混淆。
- 分片一旦上线，片键极难改，决策要慎重。
- 分片复杂度是复制集数倍，运维成本要提前评估。
下一篇讲分片集群的架构三件套：mongos、config server、shard。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MongoDB」，欢迎关注公众号 「十三Tech」。后续会按分片集群和架构选型这条线更新。
