分片应在单台mongod实例出现硬瓶颈时引入，而非仅因数据量大
MongoDB分片（Sharding）的引入时机，常被简单理解为“数据量大了就该用”。实际上，更科学的决策依据是：单台 mongod 实例在真实业务负载下，是否已触及硬件或配置的硬性瓶颈。若在此临界点仍犹豫不决，性能延迟、请求超时、写入堆积等问题将从偶发变为常态，直接影响服务稳定性。
看内存：活跃数据集是否持续压过物理 RAM 的 75%
WiredTiger存储引擎的缓存效率，核心在于工作集（Working Set）能否常驻内存。若监控指标显示 db.serverStatus().mem.resident（常驻内存）长期逼近 db.serverStatus().mem.virtual（虚拟内存），且 page faults/sec（缺页中断）持续高于10次/秒，则表明系统正频繁进行磁盘换页，I/O已成为性能瓶颈。
- 检查缓存使用率：通过
db.serverStatus().wiredTiger.cache查看"bytes currently in the cache"（当前缓存字节数）与"maximum bytes configured"（最大配置字节数）的比值，若长期高于80%则需警惕。 - 关注热点数据：例如一个存有数亿订单的系统，若查询高度集中于最近7天的数据，且这部分数据能完全装入内存，则盲目分片可能因跨分片查询而降低性能。
- SSD并非万能：固态硬盘可缓解换页延迟，但无法根除瓶颈。一旦
page faults/sec持续超过50，决策路径将清晰化：要么垂直扩展（升级单机内存），要么水平扩展（启动分片集群）。
盯连接与 CPU：mongod 或 mongos 是否开始“喘不过气”
连接数饱和、CPU使用率长期高于80%且伴随每秒操作数（ops/sec）下降，这些信号往往比磁盘问题更早出现。需特别注意一种情况：若 mongos 路由进程CPU负载很高，而各分片（Shard）负载却较低，通常表明路由层正处理低效操作，如跨分片聚合查询或范围扫描。此时，分片键设计的合理性比是否分片更为关键。
- 连接数压力：监控
db.serverStatus().connections.current（当前连接数），若频繁接近默认的net.maxIncomingConnections（通常为8192）的10%（即约800），应考虑优化或扩容。 - 写入吞吐瓶颈：当
db.serverStatus().opcounters.write（写入操作计数）持续高于每秒1.5万次，且对应分片CPU使用率持续超过80%时，基本可判定单机垂直扩展已达极限。 - 日志预警信号：
mongos日志中反复出现waitingForFlowControl（等待流控制）或waitingForLock（等待锁）信息，这是锁竞争或流控触发的征兆，通常无法通过简单增加索引解决。
验磁盘与 chunk 分布：别等爆了才动，迁移失败才是真红灯
磁盘使用率超过85%是一条明确的警戒线，但更危险的信号是Chunk迁移失败。执行 sh.status() 后，若发现部分Chunk卡在 moving 状态，且日志报错 cannot move chunk: failed to clone chunk，则表明源分片的网络或磁盘I/O已无法支撑迁移过程。此时强行操作可能引发集群级故障。
- 磁盘空间监控：通过
df -h或云平台监控工具持续观察，使用率超85%即应触发扩容或数据清理预案。 - 检查数据均衡性：在
sh.status()输出中，对比各分片的Chunk数量。若最大偏差超过平均值的2倍，且自动均衡器无法有效迁移，则很可能存在底层I/O或网络带宽不足的问题。 - 警惕写入热点：热点问题常被“磁盘总体空间充足”所掩盖。例如，若分片键采用单调递增的
_id，所有新写入将集中于最后一个Chunk，导致该分片磁盘快速耗尽，而其他分片空间闲置，形成资源浪费。
最后，一个常被忽略的关键评估点是：业务是否强依赖跨分片事务或全局唯一索引。若在分片后才发现 session.startTransaction() 频繁失败，或为维持唯一性约束而被迫将分片键设为主键前缀，则后续的架构调整成本，将远高于早期在单机架构上通过优化“忍耐”的代价。因此，分片决策需综合评估数据增长趋势、硬件瓶颈及业务特性，而非仅看数据量大小。
