deleteMany({})不能直接用于生产日志清理，因千万级文档量下易触发长锁、内存暴涨、主从延迟；须分批按_id游标删除或优先用drop()，并严防TTL索引字段类型与路径陷阱。
deleteMany({}) 不能直接用于生产日志清理
直接用 deleteMany({}) 或 deleteMany({ timestamp: { $lt: cutoff } }) 清理日志，在千万级以上文档量时极易触发长时间写锁、内存暴涨甚至主从同步延迟。它会逐条扫描索引+文档，还可能因事务超时或OOM中断，留下不一致状态。
更关键的是：如果集合有 TTL 索引，deleteMany 会绕过后台清理逻辑，导致重复删除或时间字段类型不匹配时完全失效。
- 必须确认
timestamp字段是顶层Date类型（不是字符串或嵌套字段），否则条件永远不命中 - 避免用
{}作条件——某些旧驱动版本会优化掉全表扫描逻辑，造成漏删 - 不要在高峰期执行；若集合有唯一索引或大量二级索引，性能衰减会更明显
分批 + _id 顺序游标才是安全落地方式
核心是把「范围查询 + 批量删除」拆成「按 _id 顺序分页 → 提取 ID 列表 → 小批量 deleteMany」闭环。这样能保证可续点、可控压、不锁表太久。
示例逻辑（Node.js）：
const cursor = collection.find(
{ createdAt: { $lt: cutoffDate }, _id: { $gt: lastId } },
{ sort: { _id: 1 }, limit: 500, projection: { _id: 1 } }
);
const docs = await cursor.toArray();
if (docs.length === 0) break;
await collection.deleteMany({ _id: { $in: docs.map(d => d._id) } });
lastId = docs[docs.length - 1]._id;-
sort({ _id: 1 })是硬性要求：ObjectId 天然有序，能保证每次查询不重不漏 -
projection: { _id: 1 }减少网络和内存开销，尤其当文档很大时 - batchSize 控制在 100–500 较稳妥；超过 1000 容易触发 WiredTiger 内存压力告警
- 每次删除后加
await new Promise(r => setTimeout(r, 50))可缓解集群负载
drop() 比 deleteMany 快几个数量级，但只适用于分片日志表
如果你的日志已按天/月建表（如 logs_202608, logs_20260901），drop() 是唯一真正“快速”的选择。它不走查询引擎，直接卸载元数据和数据文件，毫秒完成。
- 必须提前验证：该集合没被 Change Stream 监听，且没启用 TTL 索引（drop 后不会自动恢复）
- 分片集群中 drop 是原子操作，但若 chunk 数超 5k，balancer 清理可能短暂影响路由
- drop 后
du -sh磁盘占用不变是正常现象——WiredTiger 异步回收 .wt 文件，几小时内释放 - 别用
remove({})：MongoDB 5.0+ 已移除该方法，PyMongo 4.0+ 调用直接报错
TTL 索引适合低频写+强时效场景，但要严防字段陷阱
TTL 索引只对顶层 Date 字段生效，且依赖后台线程每 60 秒扫描一次。它不是实时删除机制，也不适合高吞吐日志写入。
常见失效原因：
- 字段名是
ts或@timestamp，且类型为字符串 → 必须入库前转成Date并存为log_time - 字段嵌套在
metadata.ts中 → TTL 不支持点号路径，必须展平 - 索引建了但没生效 → 检查
db.logs.getIndexes()输出里是否有{"key": {"log_time": 1}, "expireAfterSeconds": 86400} - 误以为 TTL 删除是即时的 → 实际延迟取决于后台线程调度，且无法控制删除批次大小
最常被忽略的一点：TTL 索引一旦建立，就无法修改 expireAfterSeconds 值，只能删了重建。而重建过程会触发全索引扫描，对大集合风险极高。
