checkMetadataConsistency返回InconsistentIndex表示分片集群索引定义元数据不一致，需连mongos执行该命令定位具体集合与缺失/冲突索引，再分别登录各shard PRIMARY节点用getIndexes({full:true})比对并手动同步createIndex参数。
元数据不一致不是数据损坏，而是各 shard 上索引定义不统一；直接重启或复制数据目录无效，必须手动对齐索引定义。
checkMetadataConsistency 返回 InconsistentIndex 怎么定位问题
这个错误不表示数据丢失或文档内容不一致，只说明某个集合在不同 shard 上的 createIndex 参数（比如 background、collation、partialFilterExpression）存在差异。常见诱因包括：在某个 shard 上单独执行了 createIndex 或 dropIndex，没走 mongos；或者块迁移中途失败，目标 shard 没来得及建索引就退出了。
操作前务必确认具体出问题的集合和索引：
- 连到
mongos运行：db.adminCommand({ checkMetadataConsistency: 1, checkIndexes: true }) - 重点看返回中每个
InconsistentIndex文档的details.namespace（如"test.users"）和details.info字段，它会明确写出「missing index」或「conflicting definition」 - 不要用
db.collection.getIndexes()在 mongos 上查——它只返回路由层聚合视图，要分别连到每个 shard 的PRIMARY节点执行db.collection.getIndexes({ full: true })才能看到完整参数
如何手动同步索引定义（不是数据）
目标是让所有 shard 的 system.indexes（4.2+ 是 config 数据库中的索引元数据）完全一致。不能靠拷文件、不能靠重启，必须逐个 shard 对齐。
步骤如下：
- 先找到权威参考：查
rs.status()，挑stateStr: "PRIMARY"的那个 shard，它通常是索引定义最可信的来源 - 在该 shard 的 PRIMARY 上运行：
db.collection.getIndexes().filter(i => i.name !== "_id_")，拿到所有业务索引的完整定义数组 - 对每个缺失索引的 shard，连到其 PRIMARY，逐个执行
createIndex，参数必须一字不差（包括background: true、expireAfterSeconds、hidden: true等） - 如果某个 shard 多出了不该有的索引，先确认应用没依赖它（比如
db.collection.explain("executionStats").find(...)是否用了该索引），再执行dropIndex
修复后必须验证的两件事
很多人执行完 createIndex 就以为结束了，但 MongoDB 不会自动把新索引纳入查询优化器的候选集，尤其当节点刚完成建索引时。
验证动作不能跳过：
- 再次运行
db.adminCommand({ checkMetadataConsistency: 1, checkIndexes: true })，确认InconsistentIndex条目清零 - 观察几次块迁移是否成功：执行
sh.status()，看balancer状态是否为OK，且各 shard 的chunks分布不再卡住 - 最关键的是查实际查询行为：在任意 shard 上运行
db.collection.explain("executionStats").find({ ... })，确认执行计划里确实用了刚同步的索引，而不是 fallback 到 collection scan
真正容易被忽略的点是：元数据一致 ≠ 查询行为一致。索引建好了，但如果没有被查询优化器选中，或者 collation 差一个字符导致无法命中，问题依然存在。修复动作本身不难，难的是验证它是否真的在生产流量里生效。
