不能在单个事务中用deletemany删除几十万条文档，因事务有60秒超时限制、内存暂存压力大，易触发transactiontoolarge、写冲突或oplog超限；须分批（≤1000 id/批）、排序、提交并显式管理session生命周期。
deleteMany 不能直接用于 MongoDB 事务中——它本身不是事务性操作，但可以在事务内调用；真正的问题是：单次事务删除大量文档极易超时、锁表、OOM 或触发 WiredTiger 内存限制。必须分批 + 提交事务 + 控制生命周期。
为什么不能在单个事务里 deleteMany 几十万条？
事务在 MongoDB 中有明确的硬约束：transactionLifetimeLimitSeconds（默认 60 秒），且所有修改必须在内存中暂存直到提交。一次删 10 万条，尤其是带复合索引或大文档时：
- WiredTiger 缓冲区可能耗尽，报错
TransactionTooLarge或WriteConflict - 主节点写锁持有时间过长，阻塞其他读写，引发延迟毛刺
- 事务日志（oplog）单条记录超 16MB 会直接失败
-
deleteMany在事务内仍走常规执行路径，不自动切片
如何用 session.startTransaction() 分批删除并提交？
核心逻辑：手动控制「查 ID → 删 ID → 提交 → 清空 session」闭环。不能依赖 deleteMany 一次性扫全量，而要用 find + deleteOne 或小批量 deleteMany 组合。
- 每次事务只处理 ≤ 1000 个
_id（稳妥值，可按文档大小下调） - 必须用
sort({ _id: 1 })+limit()保证顺序和可续点（避免漏删/重删） - 每次事务前检查
session.transaction.state === 'inactive'，异常后需abortTransaction() - 示例关键片段（Node.js 驱动）：
const session = client.startSession();
const collection = db.collection('logs');
<p>async function deleteBatchInTx(session, ids) {
await session.withTransaction(async () => {
const result = await collection.deleteMany(
{ _id: { $in: ids } },
{ session }
);
console.log(<code>Deleted ${result.deletedCount} in tx</code>);
});
}</p><p>// 主循环
let lastId = null;
const batchSize = 500;
do {
const cursor = collection.find(
{ createdAt: { $lt: cutoffDate }, _id: { $gt: lastId } },
{ sort: { _id: 1 }, limit: batchSize, projection: { _id: 1 } }
);</p><p>const docs = await cursor.toArray();
if (docs.length === 0) break;</p><p>const ids = docs.map(d => d._id);
await deleteBatchInTx(session, ids);</p><p>lastId = ids[ids.length - 1];
} while (true);
</p>
bulkWrite 能替代事务分批吗？
不能混用。虽然 bulkWrite 支持 deleteMany 操作且自带原子性（单请求内），但它不属于事务上下文，无法与插入、更新等跨集合操作构成 ACID 单元。如果你只需要删一个集合里的历史数据，bulkWrite 更轻量、更快，也无需 session 管理：
- 用
ordered: false可跳过单条失败继续执行 - 每批传入 ≤ 1000 个
deleteMany操作（注意总 BSON 大小 ≤ 48MB） - 但无法回滚其他集合的关联变更（比如同时要更新统计表）
- 错误类型是
bulkWriteError，不是事务AbortError
容易被忽略的三个细节
实际跑通后，真正卡住上线的往往不是语法，而是这些：
-
session必须显式endSession()，否则连接泄漏，MongoDB 进程内存缓慢上涨 - 时间条件字段（如
createdAt）若无索引，find扫描会变全表，分批失去意义 - 副本集环境下，
writeConcern: { w: 'majority' }在事务内默认生效，但若某节点延迟高，整个事务提交会被拖慢甚至超时
