索引与 schema 设计

3.1索引类型全景

索引是独立于集合存储的 B-tree，键是字段值、值是文档定位符；各类型的差异在于"键怎么从文档里取"。

底层机制（比文档深一层）：普通 single / compound 索引每个文档贡献一个索引项。multikey 不同——当被索引字段是数组时，索引为数组的每个元素各存一个索引项。所以一个数组字段的索引项数 ≈ 文档数 × 平均数组长度，远多于文档数。还有一条硬限制：不能对两个数组字段建复合索引（parallel arrays 限制），引擎会直接报错——因为两个数组的笛卡尔积会让索引项数爆炸。multikey 不是一种显式声明的类型，而是只要被索引字段含数组值，索引自动变成 multikey。

其余类型各自解决一类"键怎么取或取多少"的问题：partial 只索引满足 partialFilterExpression 的文档，省空间也省写入维护；sparse 只索引含该字段的文档（缺字段的不进索引）；TTL 是单字段索引加 expireAfterSeconds，后台线程周期性扫描并删除过期文档——注意是周期删除（默认约 60 秒一轮），不是到点精确即时删；hashed 索引哈希字段值，给分片场景提供均匀分布（见 06 章）；wildcard（{"$**": 1}）给字段名不固定、无法预先枚举的场景，对所有路径建索引；text 做分词全文检索，2dsphere 做地理空间查询。

3.2ESR 规则：复合索引字段顺序

复合索引字段顺序按 Equality → Sort → Range 排，能让一次索引扫描同时完成过滤、排序、范围三件事。

底层机制（比文档深一层）：复合索引 {a:1, b:1, c:1} 的 B-tree 先按 a 排序，a 相同的再按 b 排，b 相同的再按 c 排——是一棵有序嵌套的树。这个有序结构决定了三类条件该放哪：

Equality（等值）放最前——等值条件把扫描范围缩成 B-tree 上一段连续区间，选择性最高的过滤要尽早做，后面的字段才只在这一小段上工作。Sort（排序）放中间——等值段内部，索引按 Sort 字段天然有序，引擎直接顺着读出有序结果，避免内存 sort。Range（范围）放最后——范围条件（$gt/$lt）在索引上扫描一个连续子区间，放最后才不会打断前面字段的连续性。一个常见错误是把低基数字段（如布尔，只把集合切两半）放最前，那等于浪费了最前位置的选择性。

// 查询：某商户、已支付、按金额降序、金额在某区间
db.orders.find({
  merchantId: "M-100",        // Equality
  status: "paid",             // Equality
  amount: { $gte: 50, $lt: 500 }   // Range
}).sort({ createdAt: -1 })    // Sort

// 对应的 ESR 索引：先 E（两个等值），再 S，最后 R
db.orders.createIndex({
  merchantId: 1,   // E
  status: 1,       // E
  createdAt: -1,   // S
  amount: 1        // R
})
// 一次索引扫描即可过滤 + 有序输出 + 区间裁剪，无内存 sort

3.3嵌入 vs 引用：完整决策

嵌入=一次读命中、但写入会被放大；引用=避免冗余、但读取要二次查询或 $lookup。

底层机制（比文档深一层）：嵌入把"总是一起读"的数据预拼进一个文档，读取一次命中、无 $lookup；代价是更新放大（同一事实冗余在多处，改一处要改多处）和文档膨胀（逼近 16MB、挤占 WiredTiger cache，01/04 章）。引用把数据拆到独立集合，避免冗余、各自独立写；代价是读取要二次查询或走 $lookup 嵌套循环。四个判据里任何一个命中"引用"侧，就倾向引用：总是一起读吗（否→引用）、会无界增长吗（是→引用）、被多实体共享吗（是→引用）、写入时机一致吗（各自独立高频写→引用）。嵌入是默认选项，但要四个条件全部落在安全侧才成立。

3.4官方设计模式

设计模式是把"嵌入 vs 引用"这条原则在常见场景下固化成的可复用解法。

MongoDB 官方把高频建模套路整理成一组模式。逐个看，每个配上"何时用"：

Bucket（分桶）：把高频产生的小数据按时间窗或固定数量分桶，多条原始记录合并成一个"桶文档"。接 01 §1.3 的 IoT 例子——每秒一条读数若各存一文档会有海量小文档，按"设备 + 小时"分桶成一个文档、内含该小时的读数数组，既控制文档数又让数组有界。何时用：时序、日志、高频小数据。

Subset（子集）：把热子集冗余进主文档，其余引用。例如商品文档里冗余存"最近 3 条评价"供详情页直接显示，完整评价列表引用到独立集合按需翻页。何时用：一个大集合里只有一小段是高频读的。

Computed（预计算）：把读时要算的聚合结果预先算好存进文档，省去每次读时重算。例如商品文档存 avgRating 和 reviewCount，写评价时增量更新，读时直接取。何时用：读远多于写、且每次读都要做同样的聚合。

Polymorphic（多态）：一个集合存多种形态的文档，加一个 type 鉴别字段区分。例如 events 集合里 click/purchase/signup 各有不同字段，靠 type 分流处理。何时用：一组实体有共性也有差异，且常被一起查询。

Schema Versioning（schema 版本）：给文档加 schemaVersion 字段，应用层按版本兼容读取、写入时渐进迁移到新版——无需停机改全表。何时用：schema 要演进，但表大到不能一次性迁移。

Attribute（属性）：把数量可变、键不固定的属性存成 [{k, v}] 数组，再对 k 和 v 建索引，从而能按任意属性过滤。何时用：实体有大量稀疏、品类相关的可变属性（见本章 challenge）。

3.5反模式与 schema validation

反模式几乎都源自同一类错误——把无界或冗余的代价压在了写入和 cache 上；schema validation 在写入时守门。

schema validation 机制：MongoDB 允许给集合挂一个 $jsonSchema 校验器，在写入时强制结构与类型。两个开关控制严格度：validationLevel 决定校验范围（strict 校验所有写入，moderate 只校验本就合规的文档的更新），validationAction 决定违规处理（error 拒绝写入，warn 仅记日志放行）。校验器既能在 createCollection 时设，也能用 collMod 给已有集合补上。

// 给 orders 集合加 $jsonSchema 校验器（写入时强制结构 + 类型）
db.runCommand({
  collMod: "orders",
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["merchantId", "status", "amount"],
      properties: {
        merchantId: { bsonType: "string" },
        status: { enum: ["pending", "paid", "refunded"] },
        amount: { bsonType: "decimal", minimum: 0 }
      }
    }
  },
  validationLevel: "strict",   // 校验所有写入
  validationAction: "error"    // 违规直接拒绝
})