嵌入式文档设计能提升wiredtiger缓存局部性，减少跨页加载与缓存污染；但数组过大（>50项或文档>2mb）会引发分页不连续、重写开销及投影失效，需权衡拆分；分片时shard key与嵌入结构协同可降低网络io。
数据局部性直接影响WiredTiger缓存页的热数据密度
MongoDB的WiredTiger引擎依赖两级缓存：内部缓存（cacheSizeGB配置）存B-tree索引和未压缩数据页，文件系统缓存存压缩页。当一个文档的所有相关字段（如user嵌入profile、preferences）被组织在单个文档内，查询时只需加载**1个或少数几个连续页**，就能拿到全部所需字段；而若拆成多个集合（如users、profiles、settings），一次业务请求可能触发3次独立磁盘页加载，这些页在内存中分散、不连续，导致缓存页利用率下降、提前被淘汰。
嵌入结构能减少缓存“冷热混杂”带来的无效驱逐
WiredTiger按页（默认4KB）管理缓存，每页可存多个小文档或1个大文档的部分内容。如果采用引用模型，orders集合里只存userId和itemId等轻量字段，但每次查订单详情都要再查users和items——这会让缓存里塞满大量低频访问的用户元数据和商品描述，挤占真正高频访问的订单核心字段（如status、amount）的缓存空间。嵌入后，每个order文档自带关键上下文，缓存页内容与业务热点高度对齐。
数组嵌入需警惕“单页过载”反向拉低命中率
看似提升局部性，但无节制嵌入会触发负面效应：
- 单文档超过几MB时，WiredTiger会将其切分成多个页存储，这些页在磁盘上未必连续，反而破坏局部性
- 更新
comments数组末尾一条记录，可能触发整个大文档重写，导致关联的多个缓存页被标记为脏页（tracked dirty bytes in the cache升高），加速淘汰 - 查询投影（
projection）无法跳过嵌入数组中的非目标字段——即使只查title，整个comments数组仍要从缓存/磁盘读入
典型阈值：当嵌入数组预期平均长度 > 50 条，或单文档估算大小 > 2MB（按公式 ∑(字段名长度 + 字段值大小 + 10) × 1.2），就该考虑拆出独立集合并加合适索引。
分片环境下局部性还影响网络IO和路由开销
在分片集群中，shard key决定了文档物理位置。如果设计为嵌入且shard key落在父文档主键（如_id），那么一次查询能精准落到1个分片、1次网络往返；而若用userId作为shard key但把orders单独分片，查某用户全部订单可能跨多个分片，每个分片都要走一遍缓存查找+磁盘加载流程——局部性从单机内存层延伸到了分布式网络层。
profile里，只要用户登录接口高频访问该文档，整块内容就被强绑定进热区——哪怕头像URL半年才变一次。局部性不是万能解药，而是把“哪些数据必须一起热”这件事，交由文档结构显式声明。
