不能直接用 deleteMany 删除孤立文档，必须先通过 $lookup 聚合实锤确认（如 orders.userId 在 users 集合中不存在），统一字段类型，分批删除（每次1000–5000条并加间隔），删后执行 compact（需连分片 mongod）或 dump/restore 重建以释放空间，且所有操作前须 countDocuments 校验、禁用无条件 deleteMany。
直接删掉孤立文档或脏数据，不验证、不分批、不 compact，等于给数据库埋雷——删完空间不释放、查得更慢、下次还得重来。
用 deleteMany 前必须先确认哪些文档真该删
孤立文档不是靠猜出来的，得靠 $lookup 或反向查询实锤。比如 orders 集合里有 userId: 4，但 users 集合里根本没有 _id: 4 的记录，这才叫孤立。
- 别用
find().forEach()扫描全量再判断——大集合会 OOM 或超时 - 优先走聚合管道：
db.orders.aggregate([{$lookup:{from:"users",localField:"userId",foreignField:"_id",as:"user"}},{$match:{"user.0":{$exists:false}}}]}，这个比两次查询更准也更快 - 如果关联字段类型不一致（比如
userId是字符串，users._id是 ObjectId），$lookup会静默失败，得先统一类型或加$convert
删大量数据不能一把梭，得控制节奏
deleteMany 一次删几万条，WiredTiger 会产生巨量 checkpoint 和日志压力，主从延迟飙升，甚至触发流控。
- 用分批循环删：每次删 1000–5000 条，加
sleep(100)间隔，避免 I/O 打满 - 条件里必须带索引字段，否则全表扫描 + 删除 = 锁表 + 慢到卡死
- 别在高峰期跑；副本集环境下，确认
writeConcern: {w: "majority"}已设，防止删了一半主挂了，从库没同步上
删完不 compact，磁盘空间根本不会回来
MongoDB 删除文档只是标记为空闲，物理空间仍被 .wt 文件占着。storageSize 不降，size 却下降，差值就是碎片。
- 执行前先看碎片率：
db.runCommand({collStats:"orders"})，对比size和storageSize -
compact会锁整个集合，且不能在分片集群的mongos上直接运行，得连到对应shard的mongod实例执行 - 如果集合太大（>50GB），
compact可能卡住或失败，此时改用mongodump+mongorestore迁移重建更稳
误删没有后悔药，但可以提前拦住
deleteMany({}) 和 drop() 是唯二能秒清集合的操作，它们不会进 oplog 回滚，备份恢复是唯一补救路。
- 生产环境禁用
deleteMany无条件调用——Compass 或 shell 里输错一个空格就全没了 - 所有删除脚本开头必须加
db.collection.countDocuments(filter)校验，返回数为 0 或远超预期就中止 - 涉及多集合联动清理（如先删
users再删orders），务必用事务包裹，否则中间出错会导致新一批孤立数据
真正难的不是写那条 deleteMany，而是搞清“谁引用谁”“删多少合适”“删完怎么收场”。碎片不 compact、条件不预检、批量不分片——这三个点漏掉任何一个，清理就变成添乱。
