能，但仅限于未落在该分片上的数据；其余分片正常响应，mongos自动跳过宕机分片不阻塞，命中其chunk范围的操作则直接失败。
分片完全宕机后，集群是否“还能用”？
能，但仅限于未落在该分片上的数据——其余分片照常响应读写，mongos 会自动跳过不可达分片，不抛错、不阻塞（默认配置下）。但只要查询或写入命中已宕机分片的 chunk 范围，就会直接失败，报 Failed to target query 或 ShardNotFound 类错误。
为什么部分操作失败，而不是全集群雪崩？
MongoDB 分片集群天然具备“分片隔离”能力：路由层 mongos 依赖 config server 的元数据定位数据位置，一旦发现某 shard 的所有成员均无法连接（心跳超时 + 多次重试），它会将该分片标记为 UNAVAILABLE，后续请求若匹配其 chunk 范围，立即返回错误，不会卡住或降级到其他分片。这背后依赖两个关键机制：
-
sharding.chunkSize设置合理（默认 64MB），避免单个 chunk 过大导致局部故障影响面扩大 - config server 副本集健康且可读——如果 config server 全挂，
mongos就彻底“失明”，所有请求都会失败
哪些操作会直接受影响？怎么快速判断？
受影响的操作集中在三类场景，可通过 sh.status() 和日志快速交叉验证：
- 对已分片集合执行
find()时，filter 中含分片键且值落在宕机分片的 chunk 范围内 → 返回QueryNotSupportedOnShard -
updateOne()或deleteOne()没带分片键，且目标文档恰好在宕机分片上 → 报ShardNotFound（因为 mongos 无法定位） - 使用
readPreference: "nearest"或显式指定readConcern: "majority"时，若宕机分片是某个副本集的 majority 成员，可能触发写入阻塞或读取超时
实操建议：立刻在 mongos 上运行 sh.status()，重点看 shards 列表中对应分片的状态是否为 UNAVAILABLE，再查 chunks 分布，确认哪些分片键范围已“悬空”。
能绕过宕机分片继续读写吗？风险在哪？
可以临时绕过，但必须主动干预，且只适用于特定读场景：
- 对未分片集合（
sh.disableSharding("db.coll")后创建的），或数据库级未启用分片的集合，完全不受影响 - 对分片集合，可用
hint()强制走索引，但无法改变数据物理位置；真正有效的只有：连接到**其他正常分片节点**，用mongo --host shard2:27018直连方式查该分片本地数据（需业务逻辑允许） - 切勿尝试用
sh.moveChunk()手动迁移——目标分片宕机时命令会卡死或报Cannot accept sharding commands，反而拖慢均衡器
最易被忽略的一点：即使业务没报错，也要检查 config.changelog 是否堆积大量 moveChunk.start 记录——那是均衡器反复重试失败的痕迹，说明故障已开始干扰集群自愈能力。
