可以，但需构造时间范围对应的ObjectId前缀来利用_id索引：取90天前时间戳ts，起始ID为ts左补零至8位加12个0，结束ID为(ts+1)同理，查询用{_id: {$lt: endId}}。

ObjectId 生成时间戳能直接用于查询吗？

可以，但必须理解 ObjectId 的结构：前 4 字节是 Unix 时间戳（秒级），MongoDB 提供了 $expr 和 $toDate（5.0+）或 $dateFromString（4.0+）间接提取，但最高效的方式是**构造时间范围内的 ObjectId 前缀**。直接用 $expr 对每个文档计算时间戳会全表扫描，无法走索引。

如何构造时间范围对应的 ObjectId 起止值？

用时间戳生成最小和最大 ObjectId，让查询命中 _id 索引：

• 取删除截止时间（比如 90 天前）的 Unix 秒时间戳：ts = Math.floor(Date.now() / 1000) - 90 * 24 * 3600
• 构造起始 ObjectId：new ObjectId(ts.toString(16).padStart(8, '0') + '0000000000000000')（对应该秒第一毫秒）
• 构造结束 ObjectId：new ObjectId((ts + 1).toString(16).padStart(8, '0') + '0000000000000000')（对应下一秒开始，作为排他上界）
• 实际查询用 { _id: { $lt: endId } }，配合 _id 索引可毫秒级定位

执行删除时要注意哪些坑？

冷数据删除不是“删完就完”，尤其在高写入场景下：

Kibana Saved Objects

通过 REST API 管理 Kibana 保存的对象（仪表板、Lens 可视化等）。适用于：① 以编程方式创建、更新、删除仪表板和 Lens 可视化。

下载

• 避免单次 deleteMany 扫描过多文档——加 limit 分批（如每次 10000 条），用 acknowledged: true 确认结果
• 不要依赖 getTimestamp() 方法做条件——它只对已有 ObjectId 实例有效，不能用于查询谓词
• 如果集合有复合索引含 _id，确保删除操作仍能使用 _id 索引前缀；否则可能回退到 collection scan
• 副本集环境下，删除操作会同步到从节点，大批次删除可能引发 oplog 延迟，建议在低峰期执行并监控 oplogSize 使用率

有没有更安全的替代方案？

如果业务允许延迟清理，推荐用 TTL 索引替代手动删除：

• 给含时间字段的文档添加 createdAt: ISODate(...)，再建 TTL 索引：db.collection.createIndex({ createdAt: 1 }, { expireAfterSeconds: 7776000 })（90 天）
• TTL 删除由后台线程异步执行，不阻塞主流程，且自动适配副本集时钟偏移
• 但注意：TTL 索引只能基于 Date 类型字段，不能基于 _id 推导时间；若无显式时间字段，仍需走 ObjectId 前缀方案

真正关键的是别把“按时间删”想成纯应用层逻辑——_id 的时间信息是免费附带的，但要用对方式才能零成本利用它。