\_cleanuporphaned命令仅清理明确不属于任何chunk范围的孤儿文档，需先核对chunk边界连续性、抽样验证分片键值，并确保不在迁移或均衡过程中执行。
执行 _cleanupOrphaned 命令前必须确认分片键和 chunk 边界
这个命令不是“一键清垃圾”，它只清理那些**明确不属于任何 chunk 范围**的文档。如果分片键值类型被误判（比如把 NumberLong 当成 NumberInt）、或手动拆分/迁移后 chunk 元数据没同步，_cleanupOrphaned 可能漏删，甚至误删正常数据。
实操建议：
- 先在目标分片上运行
db.getSiblingDB("config").chunks.find({ ns: "your_db.your_col" }).sort({ min: 1 })，核对 chunk 的min/max范围是否连续、无重叠 - 用
db.your_col.findOne()抽样检查几条疑似孤儿文档的分片键值，确认它确实落在所有 chunk 范围之外 - 禁止在 chunk 正在迁移或 balancer 运行中执行该命令——会返回
"cannot cleanup orphaned data while balancing"
后台回收机制（orphanCleanupDelaySecs）默认不启用且延迟不可控
MongoDB 确实有自动回收逻辑，但它依赖一个隐藏配置 orphanCleanupDelaySecs，而且**只在 mongod 启动时读取一次**，运行时修改无效。默认值是 900 秒（15 分钟），但前提是：该分片上发生过 chunk 迁移，且迁移源端残留了文档。
实操建议：
- 查看当前生效值：连接到分片 mongod，运行
db.adminCommand({ getCmdLineOpts: 1 }).parsed.sharding.orphanCleanupDelaySecs - 若要启用，必须重启 mongod 并在配置文件中显式设置，例如：
sharding: { orphanCleanupDelaySecs: 300 } - 注意：这个延迟是“从迁移完成开始计时”，不是实时扫描；且不会处理手动插入到错误分片的文档（即非迁移产生的孤儿）
_cleanupOrphaned 是单分片操作，不能跨分片批量触发
你得登录到每个疑似存在孤儿文档的分片 mongod（不是 mongos），逐个执行。它不接受数据库名或集合名参数，必须先 use 到对应库，再指定集合名作为字符串传入：
use your_db
db.runCommand({ _cleanupOrphaned: "your_col" })
常见错误现象：
- 在 mongos 上执行 → 返回
"not master"或直接报错，因为这是分片本地命令 - 传入
"your_db.your_col"（带库名）→ 返回"ns does not match expected format" - 集合名拼错或不存在 → 静默成功但实际没做任何事（命令不校验集合是否存在）
真正难清理的是“伪孤儿”：分片键变更或应用写入逻辑错误导致的数据错位
_cleanupOrphaned 和后台机制都只认 chunk 元数据，对“本该属于 A 分片、却因应用层路由错误写到了 B 分片”的数据完全无感。这类文档分片键合法、范围匹配，只是业务逻辑上错了。
这种场景只能靠人工识别+脚本迁移：
- 用
db.your_col.find().limit(10).forEach(printjson)检查分片键分布是否符合预期 - 对比 config.shards / config.databases 确认分片数量与实际写入分片是否一致
- 如果发现某分片长期写入量远低于其他分片，大概率存在路由错误，需回溯应用代码里的
shardKey构造逻辑
清理本身不难，难的是判断“它到底算不算孤儿”。别迷信命令输出的 "ok: 1"，多看一眼 chunk 范围，再查一条文档的分片键值。
