MongoDB如何评估是否需要开启分片？基于数据增长趋势与硬件瓶颈分析

分片应在单台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() 频繁失败，或为维持唯一性约束而被迫将分片键设为主键前缀，则后续的架构调整成本，将远高于早期在单机架构上通过优化“忍耐”的代价。因此，分片决策需综合评估数据增长趋势、硬件瓶颈及业务特性，而非仅看数据量大小。