分片应在单台mongod实例出现硬瓶颈时引入，而非仅因数据量大：内存持续超75%、page faults/sec＞10、连接数常超800、CPU长期＞80%、chunk迁移失败或磁盘使用率＞85%等任一指标持续异常即为触发信号。
分片不是“数据量大了就该上”，而是单台 mongod 实例在真实负载下已触达硬性瓶颈——此时再不上，延迟、超时、写入堆积就会变成日常。
看内存：活跃数据集是否持续压过物理 RAM 的 75%
WiredTiger 缓存不是越大越好，关键看工作集（working set）是否能常驻内存。如果 db.serverStatus().mem.resident 长期接近 db.serverStatus().mem.virtual，且 page faults/sec 稳定 >10，说明频繁换页，磁盘已在拖后腿。
- 用
db.serverStatus().wiredTiger.cache查当前缓存使用：重点关注"bytes currently in the cache"和"maximum bytes configured"的比值 - 不要只看总数据量——5000 万订单若查询集中在最近 7 天，而这些数据刚好 fit 进内存，那分片纯属添乱
- SSD 能缓解但不能根治 page fault；一旦出现持续 >50 faults/sec，单机扩容（加内存）或分片就得二选一
盯连接与 CPU：mongod 或 mongos 是否开始“喘不过气”
连接数打满、CPU 长期 >80% 且伴随 ops/sec 下降，是比磁盘更早暴露的信号。尤其注意 mongos 的 CPU：如果它高而各 shard 负载不高，说明路由层在扛重活（比如跨分片聚合或低效范围扫描），这时分片键设计比是否分片更关键。
- 查连接压力：
db.serverStatus().connections.current是否经常 >800（默认net.maxIncomingConnections上限） - 查写入瓶颈：
db.serverStatus().opcounters.write持续 >15k/sec 且对应 shard 的top显示 CPU >80%，基本没得救，垂直扩展已到头 - 别忽略
mongos日志里反复出现的waitingForFlowControl或waitingForLock，这是锁排队前兆，不是等索引能解决的
验磁盘与 chunk 分布：别等爆了才动，迁移失败才是真红灯
磁盘使用率 >85% 是显性红线，但更危险的是 chunk 迁移失败。执行 sh.status() 后若发现某些 chunk 卡在 moving 状态，日志里报 cannot move chunk: failed to clone chunk，说明原 shard 的网络或磁盘 I/O 已慢到无法支撑迁移本身——此时强行分片只会让整个集群雪崩。
- 监控单 shard 磁盘：用
df -h或云平台磁盘使用率指标，>85% 就该预警 - 检查 chunk 均衡：
sh.status()输出中看各 shard 的 chunk 数是否偏差 >2× 平均值；偏差大但迁移不动，大概率是底层 I/O 或网络带宽不足 - 写入热点会伪装成“磁盘还够用”：比如分片键选了单调递增的
_id，新数据全写进最后一个 chunk，那个 shard 磁盘涨得飞快，其他 shard 却很空
最容易被跳过的判断点是：业务是否强依赖跨分片事务或全局唯一索引。一旦上了分片又发现 session.startTransaction() 频繁失败，或不得不为唯一约束把分片键设成业务主键前缀，重构成本远高于早期忍一忍单机。
