分片环境文档模型设计需严守三原则：分片键必须参与所有高频查询且不可为数组或嵌套路径；嵌入式结构须规避跨分片事务与文档膨胀；关联查询应优先内嵌，引用时确保被引用集合未分片或分片键一致。

分片环境下的文档模型设计，不是简单把单机模型复制过去就能跑通——分片键选错、嵌套结构不合理、跨分片查询频繁，三者任一出问题，集群吞吐量就断崖式下跌。

分片键必须参与所有高频查询条件

分片键决定数据落在哪个 shard 上，MongoDB 只有在查询中明确包含分片键时，才能路由到目标 shard；否则触发广播查询（all shards），性能归零。

• 错误写法：db.orders.find({ status: "pending" }) —— 没带分片键，全集群扫描
• 正确写法：db.orders.find({ user_id: "u123", status: "pending" }) —— 前置分片键，精准路由
• 分片键字段不能是数组或嵌套路径（如 "address.city"），否则无法哈希或范围分片
• 高基数 + 低写入热点字段优先：比如 user_id 比 status 更适合作为分片键

嵌入式结构要避开跨分片事务和文档膨胀

MongoDB 分片集群中，multi-document transaction 仅支持在单个分片内执行；跨分片事务要么失败，要么被拒绝。同时，文档超过 16MB 或频繁重写导致的文档迁移，会严重拖慢 chunk 迁移速度。

• 订单详情适合嵌入：items 数量稳定（通常 ≤ 50）、总大小可控，且与 order_id 强绑定
• 用户行为日志不适合嵌入：如果一个用户每天产生数百条日志，logs: [ ... ] 会导致文档持续膨胀，最终触发 moveChunk 频繁迁移
• 替代方案：用独立集合 + 复合分片键，例如 { user_id: ..., date: ... }，既保证局部性，又避免单文档过大

关联查询必须提前规划引用方式

分片环境下 $lookup 仅支持“左表分片键 = 右表字段”且右表必须是未分片集合（或使用 let + $expr 但性能极差），硬做跨分片关联等于自废武功。

• 能内嵌绝不引用：地址、配置项、状态变更历史等低频更新、小体积数据，直接塞进主文档
• 必须引用时，确保被引用集合不启用分片（如 products 表），或让引用字段与主表分片键一致（如订单引用商品，商品按 category_id 分片，而订单也按 category_id 分片）
• 禁用 DBRef：它不提供任何路由优化，反而增加一次额外查询，且 driver 层不自动解析

索引必须覆盖分片键+查询模式

分片集群里，索引建在非分片键字段上，只在单个 shard 内有效；但若缺失分片键前缀，即使有索引，查询仍需广播。

• 坏索引：db.orders.createIndex({ created_at: 1 }) —— 单独建时间索引，对分片无意义
• 好索引：db.orders.createIndex({ user_id: 1, created_at: 1 }) —— 分片键前置，支持 { user_id: ..., created_at: { $gt: ... } } 高效查询
• 排序字段必须进索引：分片环境下 sort() 不走索引 = 全 shard 内存排序，极易触发 Sort operation used more than the maximum 33554432 bytes of RAM

真正卡住人的从来不是语法，而是“这个字段该不该嵌进去”“那个查询会不会广播”“这次加索引会不会让 chunk 迁移卡死”——这些判断没有银弹，全靠对业务读写比例、数据增长节奏、分片拓扑的实时感知。