sh.checkmetadataconsistency是mongodb 7.0+分片集群元数据一致性诊断命令，仅在mongos上执行，返回不一致类型及文档，需人工验证修复，不自动修复、不检查数据内容或config库损坏。
直接结论：sh.checkMetadataConsistency 是 MongoDB 7.0+ 分片集群元数据一致性检查的权威入口，但它不是“一键修复”工具，而是诊断器——输出的是不一致类型和具体文档，后续必须人工介入验证和修正。
sh.checkMetadataConsistency 命令怎么用？
该命令只能在 mongos 实例上执行，且需具备 clusterAdmin 或 clusterManager 权限。它默认扫描整个集群所有分片集合，耗时较长，生产环境建议指定范围：
- 检查单个数据库：
sh.checkMetadataConsistency({ db: "mydb" }) - 检查单个集合：
sh.checkMetadataConsistency({ ns: "mydb.mycoll" }) - 跳过索引检查（仅查路由/UUID/zone等）：
sh.checkMetadataConsistency({ skipIndexChecks: true }) - 限制返回不一致项数量（防结果爆炸）：
sh.checkMetadataConsistency({ limit: 100 })
注意：sh.checkMetadataConsistency 不会阻塞读写，但会触发各分片主动比对本地元数据与 config 库内容，高负载集群建议错峰执行。
常见不一致类型对应的现象和定位路径
命令输出中的 type 字段是关键线索，每种类型指向不同层级的问题：
-
CollectionUUIDMismatch：某个分片上集合的本地_id（即 UUID）和config.collections中记录的不一致 → 直接查config.collections和对应分片的local.oplog.rs起始点或迁移日志 -
InconsistentIndex：索引定义在分片间不统一（字段顺序、选项、稀疏性等）→ 必须连到每个分片PRIMARY，运行db.mycoll.getIndexes()逐一对比 -
RoutingTableRangeGap或RoutingTableRangeOverlap：路由表存在空洞或重叠 → 用sh.status()查块分布，再用db.chunks.find({ ns: "mydb.mycoll" }).sort({ min: 1 })检查边界连续性 -
MisplacedCollection：未分片集合被误写入非主分片 → 看config.databases中该库的primary字段，再确认集合物理位置
这些类型不会自动修复，sh.checkMetadataConsistency 只负责暴露它们。
为什么不能只依赖这个命令？容易踩的坑
这个命令本身有明确局限，忽略会导致误判或漏判：
- 它不检查数据内容一致性（比如同一
_id在不同分片存了不同值），只管元数据结构 - 它无法发现
config库自身损坏（如config.collections文档被手动篡改但格式合法） - 某些错误类型（如
CorruptedChunkShardKey）需要结合分片日志里的migrate failed错误交叉验证，否则可能误以为是配置问题而非迁移中断残留 - 8.2 新增的
TrackedUnshardedCollectionHasInvalidKey类型，要求你额外确认该集合是否曾被错误地加入分片跟踪但未真正分片
真正棘手的元数据不一致，往往藏在「多个错误类型共存」的场景里——比如先有 InconsistentIndex 导致块迁移失败，进而产生 RoutingTableRangeGap 和 MissingRoutingTable，此时必须按因果链逆向排查，不能只看第一个报错。
