sh.checkMetadataConsistency仅诊断元数据不一致，不刷新路由表；真正触发mongos重载config数据的是flushRouterConfig命令，需手动执行于mongos上。
sh.checkMetadataConsistency 只暴露问题，不刷新路由表
执行 sh.checkMetadataConsistency 后发现 RoutingTableRangeGap 或 MisplacedCollection，不代表调用它就能让 mongos 重新加载正确路由。这个命令纯属诊断，和路由缓存完全无关。真正触发 mongos 主动拉取最新 config 数据的，是 flushRouterConfig。
什么时候必须手动 flushRouterConfig？
常见于以下操作后 mongos 仍返回旧路由、查询打到错误分片、sh.status() 显示块分布与 db.chunks.find() 不一致：
- 手动修改了
config.chunks或config.collections（比如紧急修复 UUID） - 执行了
moveChunk、splitChunk等底层命令但 balancer 未参与 - config server 切换主节点后，mongos 缓存未自动失效（尤其跨版本升级后）
- 添加/移除 shard 后
sh.status()看不到新分片，或 chunk 分布卡在旧状态
flushRouterConfig 怎么用？权限和范围要注意
该命令必须在 mongos 上以 clusterAdmin 或 root 角色执行，且只对当前连接的 mongos 生效——其他 mongos 实例需单独执行：
- 刷新整个集群路由：
db.adminCommand({flushRouterConfig: 1}) - 只刷新某数据库的路由（减少影响）：
db.adminCommand({flushRouterConfig: 1, db: "mydb"}) - 只刷新某集合路由（最精准）：
db.adminCommand({flushRouterConfig: 1, ns: "mydb.mycoll"})
注意：flushRouterConfig 不阻塞读写，但会引发短暂（通常
为什么 flushRouterConfig 有时没效果？
不是所有元数据不一致都能靠刷新解决。以下情况即使执行了也无效：
-
CollectionUUIDMismatch：config 和分片本地 UUID 对不上，flushRouterConfig不会重写 UUID，必须人工同步或重建集合 -
CorruptedChunkShardKey：chunk 元数据里 shard key 值损坏，需查分片日志定位迁移失败点，不能仅靠刷新 - config server 自身数据损坏（如
config.databases被误删字段），刷新只会把坏数据再加载一遍 - mongos 版本低于 config server，协议解析失败导致刷新后仍 fallback 到空路由表（见版本兼容性问题）
真正关键的不是“要不要刷”，而是刷之前确认 config 库内容是否可信——flushRouterConfig 是把 config 的当前快照强制推给 mongos，如果源头错了，结果只会更错。
