根本原因是updateMany在事务或高并发下因无索引导致全表扫描、文档级锁持有时间过长，引发WriteConflict；需建匹配索引、确保分片键路由、拆批处理并错峰执行。
根本原因不是 updateMany 本身加锁，而是它在事务中或高并发下触发了文档级写锁竞争，且缺乏索引导致扫描范围过大、锁持有时间过长。
updateMany 在事务中会持锁直到提交
事务内执行 updateMany() 时，MongoDB 对所有匹配文档逐个加写锁（WiredTiger 的文档级锁），这些锁不会在单次操作后释放，而是持续到整个事务 commitTransaction() 或中止。如果事务里还有其他读写操作、或者事务执行慢，锁就一直挂着。
- 常见错误现象：多个事务同时尝试更新同一组文档，后发起的事务抛出
WriteConflict错误，而不是等待 - 默认锁等待超时仅 5 毫秒（由
maxTransactionLockRequestTimeoutMillis控制），超时即失败，不排队 - 不要盲目调大这个值——它只是把冲突报错延后，不能解决锁争用本质
无索引或低效索引导致扫描膨胀，锁时间翻倍
updateMany() 若没走索引，就会触发全集合扫描（COLLSCAN），每扫一个文档都可能加锁、判断条件、再决定是否更新。扫描越久，锁占用窗口越宽，冲突概率指数上升。
- 用
explain("executionStats")检查：若totalDocsExamined远大于nMatched（比如 10 万 vs 100），说明大量无效扫描 - 复合索引必须前导字段匹配查询条件，例如
{ status: 1, createdAt: -1 }支持{ status: "pending" }，但不支持仅{ createdAt: { $gt: ... } } - 避免在
updateMany()条件中用$regex（尤其非前缀）、$where、或未索引字段做范围查询
分片集群下无分片键引发广播写，锁争用放大
对分片集合执行 updateMany() 时，如果写语句不含分片键（或类型不匹配），mongos 无法路由到具体分片，只能广播到所有分片。每个分片都执行一遍全量扫描+加锁，相当于把锁冲突从 1 个分片扩散到 N 个。
- 典型表现：
mongostat显示qw（写入队列）飙升，但各分片的insert/update指标却很低——说明卡在路由层 - 检查方式：在 config server 上开启慢日志（
db.setProfilingLevel(2, {slowms: 10})），搜planSummary: "SHARDING_FILTER" - 修复动作：确保每次
updateMany()都显式带分片键字段，且值非空、类型一致（如分片键定义为{user_id: "hashed"}，传入值必须是数字，不能是字符串）
高频批量更新直接冲击锁资源，替代方案更可控
业务中常见的“迁移字段”“补默认值”等操作，如果直接用 updateMany() 扫全表，等于主动制造锁风暴。稳定做法是放弃原子性，换控制力。
- 拆批次：用
find().limit(1000).toArray()拿 ID 列表，再用bulkWrite([{ updateOne: { filter: { _id: ... } } }])更新，每次事务只包少量文档 - 加随机延迟：不同批次间 sleep(10–100ms)，错开锁请求高峰
- 双写过渡：新旧字段并存，后台任务逐步补全，最后灰度切读路径——避免任何一次强一致性“改结构”
- 禁用
updateMany()在高峰期执行；可用db.collection.find({oldField: {$exists: true}}).limit(1)快速探活，确认无写入后再操作
最容易被忽略的是：锁等待问题往往不是单点配置能解的，它横跨索引设计、分片路由、事务粒度、应用节奏四个层面。少调一个参数，多建一个索引，晚跑一小时任务，效果可能远超拉长超时时间。
