MongoDB 大文档更新优化的核心是减少文档移动和缩小锁持有时间，默认 WiredTiger 引擎下使用文档级锁，但文档增长导致的页分裂仍会影响性能。避免锁竞争的关键在于合理设计 schema、使用原子操作符以及必要时引入分片。
先说结论：优先使用 WiredTiger 存储引擎的文档级锁特性，通过 schema 设计避免文档频繁扩容，并结合原子更新操作符减少锁持有时间。
- 先定位：使用 db.currentOp() 确认是否存在长时间运行的更新操作或锁等待。
- 先做：将大字段拆分或使用 Bucket 模式，避免单文档接近 16MB 限制或频繁移动。
- 再验证：观察 db.serverStatus() 中的锁等待指标和更新延迟是否下降。
命令速用版
以下命令用于快速查看当前锁状态和慢更新：
db.currentOp({"secs_running": {"$gt": 1}})db.collection.find({"_id": ...}).explain("executionStats")若发现大量写锁等待，检查是否有未命中索引的全集合更新。
为什么会这样
MongoDB 3.0 之后默认 WiredTiger 引擎支持文档级锁，但文档大小变化仍可能触发页分裂。
早期 MMAPv1 引擎使用集合级锁，单个大文档更新会阻塞整个集合的读写。WiredTiger 虽然细化到文档级，但当更新导致文档大小显著增加且原位置无法容纳时，数据库需要移动文档物理位置，这会消耗 I/O 并可能引发页锁竞争。此外，未索引的更新操作需要扫描更多记录，间接延长锁持有时间。
分步处理
第一步：检查存储引擎和锁粒度
确认实例使用 WiredTiger 引擎，命令为 db.serverStatus().storageEngine。若仍为 MMAPv1，需规划升级迁移。
第二步：优化 Schema 设计
对于日志或时间序列数据，采用 Bucket 模式将多个事件存入一个文档，减少文档数量和更新频率。避免在单个文档中存储无限增长的数组。
第三步：使用原子操作符
更新时使用 $set、$inc 等操作符，避免拉取整个文档修改后全量回写。对于数组，使用 $addToSet 或带 $slice 的 $push 控制大小。
第四步：引入分片
若单集合写入压力过大，按业务键进行分片，将锁竞争分散到不同 Shard 节点。
怎么验证是否生效
执行更新操作后，运行 db.currentOp() 观察 active 写操作数量是否减少。
检查 db.serverStatus().locks 相关指标，确认写锁等待时间降低。
监控应用层更新接口的 P99 延迟，确认无明显抖动。
常见坑
1. 全量替换文档：直接使用 save() 或 replaceOne() 会导致整个文档重写，增加锁持有时间和 I/O。
2. 无索引更新：更新条件未命中索引会触发全表扫描，长时间持有锁。
3. 数组无限增长：频繁 $push 导致文档不断扩容移动，产生碎片。
常见问题
MongoDB 单文档大小限制是多少？
BSON 文档最大限制为 16MB，超过该大小无法写入。
WiredTiger 引擎是文档级锁吗？
是，WiredTiger 引擎默认使用文档级锁，但元数据操作仍可能使用数据库级锁。
如何避免更新时的锁竞争？
确保更新条件命中索引，使用原子操作符，并避免热点文档的高频并发写入。
参考来源
- MongoDB Manual, Storage Engines, https://www.mongodb.com/docs/manual/storage-engines/
- MongoDB Manual, Write Operations, https://www.mongodb.com/docs/manual/core/write-operations/