sh.status() 返回不完整或报错是常见误判信号，真正问题在于返回空、卡住或“not connected to a mongos”错误；需确认连接mongos而非mongod，检查ismaster中"isdbgrid"，config元数据须经mongos访问，均衡器状态需为stopped:false，片键与chunk分布异常会导致写入后读不到，mongos超时多因底层通信中断而非网络问题。
sh.status() 返回不完整或报错
这是最常见也最容易误判的信号。执行 sh.status() 时若看到 too many chunks to print, use verbose if you want to force print，不代表集群不可用，只是 chunk 数量超限被截断。真正的问题是返回空、卡住、或抛出 not connected to a mongos 错误。
实操建议：
- 先确认连接的是
mongos实例（端口默认 27017），不是某个分片的mongod；可通过db.runCommand({isMaster: 1})检查msg字段是否含"isdbgrid" - 若返回
NetworkTimeout或Failed to refresh topology，说明mongos无法连上配置服务器，需检查 config server 副本集状态 - 加
true参数强制输出完整信息：sh.status(true)，但仅用于诊断，生产环境避免频繁调用
config 数据库查询失败
所有分片元数据都存在 config 数据库里，但它不是普通数据库——不能直接连 config server 访问，必须经由 mongos 路由。如果 use config 后 show tables 报错或返回空，基本可判定集群路由层异常。
实操建议：
- 执行
db.getSiblingDB("config").shards.find().toArray()，应返回至少一个分片文档；若报command not allowed，说明当前用户缺少clusterAdmin或root权限 - 检查
config.settings中balancer状态字段，{ "_id" : "balancer", "stopped" : false }才表示均衡器正常启用 - 禁止直接连接 config server 节点执行写操作，哪怕只是
insert一条测试数据——这会破坏集群一致性
写入成功但读不到新数据
典型症状：插入文档返回 acknowledged: true，但立刻用相同查询条件查不到；或者只在部分分片上能查到。这往往不是集群“不可用”，而是片键设计或 chunk 分布异常导致路由失效。
实操建议：
- 用
sh.status()查看目标集合的shard key和chunks分布，确认该片键值实际落在哪个分片上 - 手动指定分片执行查询：
db.getSiblingDB("config").chunks.findOne({ ns: "mydb.mycoll", min: { x: 1 } })，比对shard字段和实际写入节点是否一致 - 检查是否有未迁移完的 chunk：执行
db.getSiblingDB("config").chunks.countDocuments({ shard: "shard01" })，结合sh.status()中各分片 chunk 数对比
连接 mongos 但命令超时
mongos 进程存活、端口可通，但任意命令（如 db.stats()）响应超过 30 秒甚至直接 hang 住，大概率是底层组件通信中断，而非网络问题。
实操建议：
- 登录
mongos主机，用mongostat --host localhost:27017观察insert/query是否为 0，若持续为 0，说明 mongos 已失去与分片或 config 的心跳 - 检查
mongos日志中是否有could not find host in replica set或failed to connect to config server类错误 - 验证配置服务器副本集状态：
rs.status()在 config server 主节点上执行，确认members[n].stateStr全部为PRIMARY或SECONDARY，无DOWN或STARTUP2
