文档移动开销是MongoDB写入性能的隐形杀手，源于WiredTiger就地更新失败后触发的整文档迁移、索引重写与额外I/O，主因是文档膨胀超出预留空间，可通过拆分集合、限制数组、外存大字段及监控avgObjSize/maxSize差值等手段主动规避。
大文档移动开销（Document Movement）是MongoDB写入性能的隐形杀手——它不是报错，不抛异常，但会让 update 变慢、insert 延迟升高、磁盘IO持续拉满，尤其在高频更新场景下，数据库会悄悄“变重”。根本原因在于：WiredTiger引擎默认使用“就地更新（in-place update）”策略，但当更新后文档体积膨胀超过原空间时，MongoDB必须把整个文档挪到新位置，并更新所有相关索引项。这个过程会锁住文档、触发额外I/O、放大写放大效应。
为什么文档会“被移动”而不是原地更新
WiredTiger为每个文档预留了少量填充空间（padding），但仅限于小幅度增长。一旦字段值变长（比如字符串追加、数组 $push 新元素）、或嵌套结构深度增加，超出预留空间，就必须迁移。常见诱因包括：
-
$push无限制向数组追加，尤其未设上限或未做归档 - 字符串字段被反复
$set成更长内容（如日志拼接、HTML片段累积） - 嵌套文档动态添加新键（如
{config: {theme: "dark", lang: "zh"}} → {config: {theme: "dark", lang: "zh", version: "2.1.0", debug: true}}） - 使用
$inc导致数字字段位宽变化（虽小，但叠加 padding 策略失效时也会触发）
如何用 writeConcern 和 storageEngine 配置缓解
这不是靠配置能根治的问题，但可以降低影响范围和可见性：
- 禁用
usePowerOf2Sizes（已弃用）或padInserts（旧版MMAPv1），现代 WiredTiger 不再支持这些填充策略；不要试图开启它们 - 确认
storage.wiredTiger.engineConfig.configString中没有手动设置allocation_size或internal_page_max—— 这些底层参数调优需 DBA 级别验证，误配反而加剧碎片 -
writeConcern: { w: "majority" }不影响移动本身，但能避免主节点宕机前文档刚迁完还没复制就丢失，属于兜底保障，不是性能解法
真正有效的建模规避手段
核心思路是：让文档大小可控、可预测、不随时间单向膨胀。
- 对“一对多”中“多”的部分，坚决不用内嵌数组，改用独立集合 + 引用：比如用户操作日志、商品评论、设备传感器点位数据，都应拆出
user_logs、product_reviews、sensor_readings集合，用userId/productId/deviceId建索引 - 若必须保留数组，加长度限制并配合归档逻辑：例如
recent_errors: { $slice: -50 }配合定时任务将旧错误移入历史集合 - 避免在文档里存二进制、Base64图片、长文本缓存 —— 这些应走对象存储（如 S3/MinIO），MongoDB 只存 URL 和元数据
- 对频繁更新的字段，单独拎出来建小文档：比如一个订单文档包含
status、payment_status、shipping_status，可拆成order_status子集合，用orderId关联，每次只更新状态文档，主文档保持稳定
怎么确认你已经踩了坑
别等业务报警，主动查：
- 运行
db.collection.stats()，重点关注avgObjSize和maxSize的差值 —— 如果后者远大于前者（比如 >3×），说明存在严重大小离散，易触发移动 - 检查慢日志：
db.setProfilingLevel(1, { slowms: 100 })，然后查system.profile中millis高但nReturned小的update操作，这类往往伴随文档迁移 - 用
explain("executionStats")看executionStages.stage === "UPDATE"下的docsExamined是否远大于nMatched—— 若是，大概率在挪文档找空闲页
文档移动开销最难缠的地方在于：它不发生在你写代码那一刻，而是在数据量涨到某个临界点之后才集中爆发。等到 db.collection.validate(true) 报出 “data file fragmentation” 或 wt 工具显示 page utilization
