4.2.2 MongoDB · 文档模型与关系模型转换 + 索引 + 分片实战

1. 为什么这个专题重要

1.1 关系模型的 4 大痛点

传统 RDBMS(MySQL/PostgreSQL)遵循「模式固定(Schema-on-Write)」,在 4 类典型场景下力不从心:

1.2 为什么需要文档数据库

MongoDB 采用 Schema-on-Read(读时模式)+ BSON 文档(Binary JSON)+ 原生水平扩展(分片),正好命中上述 4 大痛点。一个 Document 对应业务对象,天然贴合面向对象编程。

1.3 三种 JSON 存储方案对比

调研依据:[1] MongoDB 官方文档;The Definitive Guide to MongoDB(K. Banker);MongoDB 权威指南(Kristina Chodorow);MongoDB 实战( Kyle Banker);[5] MongoDB 性能优化白皮书。

2. MongoDB 文档模型

2.1 BSON 数据类型

MongoDB 使用 BSON(Binary JSON)序列化,支持比 JSON 更丰富的类型:

block-beta
columns 2
A["BSON Type"]:2
B["Double"] C["3.14"]
D["String"] E["hello"]
F["Object"] G["{a 1, b 2}"]
H["Array"] I["1, 2, 3"]
J["ObjectId"] K["ObjectId()"]
L["Date"] M["ISODate 2026-07-06"]
N["Int32 / Int64"] O["NumberLong"]
P["Decimal128"] Q["货币高精度"]
R["Binary"] S["文件/图片"]
T["Boolean / Null"] U["true / null"]

2.2 嵌套 vs 引用:Linked Document

两种核心关系建模方式:

嵌入式(Embed):子文档塞进父文档,一次查询拿全。

// 用户 + 多个地址嵌入
db.users.insertOne({
  _id: ObjectId("u001"),
  name: "张三",
  addresses: [
    { type: "home", city: "杭州", zip: "310000" },
    { type: "work", city: "上海", zip: "200000" }
  ]
})

引用式(Linked Document):只存对方 _id,靠应用层/聚合 $lookup 拼装。

// 用户 + 订单分离
db.orders.insertOne({
  _id: ObjectId("o001"),
  user_id: ObjectId("u001"),  // 引用
  total: 299.00,
  items: [...]
})

2.3 模式设计 6 原则

1. One-to-Few → Embed(一对少量,优先嵌入,如用户地址)
2. One-to-Many → Link(一对万级,引用 + 分桶,如订单)
3. One-to-Squillions → Link + Bucket Pattern(一对无限,引用 + 分桶模式,如 IoT 设备日志按天分桶)
4. 避免无限增长数组(评论分页 / 拆分子集合)
5. 优先读性能,写可冗余(空间换时间)
6. 拒绝 JOIN 上瘾(能 Embed 不 Lookup)

2.4 真实案例:用户 + 订单 + 商品 3 种设计对比

方案 A:全规范化(关系思维,反模式)

// 3 张集合全靠外键
users: { _id, name }
orders: { _id, user_id, product_id }
products: { _id, name, price }
// 查一个用户的所有订单:2 次 $lookup,慢

方案 B:订单嵌入商品快照(推荐)

db.orders.insertOne({
  _id: ObjectId("o001"),
  user_id: ObjectId("u001"),
  created_at: ISODate("2026-07-06"),
  items: [
    { sku: "P-001", name: "机械键盘", price: 599.00, qty: 1, snapshot_at: ISODate(...) },
    { sku: "P-002", name: "鼠标垫",   price: 49.00,  qty: 2, snapshot_at: ISODate(...) }
  ],
  total: 697.00,
  status: "paid"
})

商品名/价格冗余存到订单里 —— 即便商品改名/调价,历史订单显示仍正确。

方案 C:商品中心嵌套多规格(SPU/SKU)

db.products.insertOne({
  _id: ObjectId("p100"),
  spu: "T-Shirt-2026",
  name: "夏季纯棉 T 恤",
  category: ["服装", "上衣"],
  specs: [
    { sku: "T-Shirt-2026-red-M",   color: "红", size: "M", stock: 100, price: 99 },
    { sku: "T-Shirt-2026-blue-L",  color: "蓝", size: "L", stock: 50,  price: 99 }
  ],
  attrs: { material: "纯棉", origin: "杭州" },
  tags: ["夏季", "新品", "热销"]
})

3. MongoDB 索引详解

索引是 MongoDB 性能的生命线,无索引 = 全集合扫描 COLLSCAN(百万级数据秒级 → 分钟级)。

3.1 索引全景图

block-beta
columns 2
A["索引类型"]:2
B["Single Field"] C["单字段等值/范围"]
D["Compound"] E["多字段组合查询"]
F["Multikey (数组)"] G["数组字段查询"]
H["Text"] I["全文搜索(分词)"]
J["2dsphere / 2d"] K["地理空间 GEO"]
L["Hashed"] M["等值 + 哈希分片"]
N["TTL"] O["自动过期(日志/Session)"]
P["Partial"] Q["条件索引(节省空间)"]
R["Unique"] S["唯一约束"]
T["Sparse"] U["稀疏索引(跳过 null)"]

3.2 索引 CRUD 完整代码

// === 1. 单字段索引 ===
db.products.createIndex({ category: 1 })          // 升序
db.products.createIndex({ created_at: -1 })       // 降序

// === 2. 复合索引(ESR 法则:Equality, Sort, Range) ===
// 查询:status=X AND created_at range,按 price 排序
db.orders.createIndex({ status: 1, price: 1, created_at: -1 })

// === 3. 多键索引(数组字段自动 multikey) ===
db.products.createIndex({ tags: 1 })              // tags: ["夏季","新品"]
db.products.find({ tags: "夏季" })               // 命中索引

// === 4. 文本索引(全文搜索) ===
db.products.createIndex(
  { name: "text", description: "text" },
  { weights: { name: 10, description: 1 }, default_language: "chinese" }
)
db.products.find({ $text: { $search: "机械键盘 静音" } })

// === 5. 地理空间索引(2dsphere) ===
db.stores.createIndex({ location: "2dsphere" })
// 查附近 1km 的店
db.stores.find({
  location: {
    $near: {
      $geometry: { type: "Point", coordinates: [120.15, 30.27] },
      $maxDistance: 1000
    }
  }
})

// === 6. Hash 索引(只支持等值,用于哈希分片) ===
db.users.createIndex({ user_id: "hashed" })

// === 7. TTL 索引(自动过期删除) ===
db.sessions.createIndex({ created_at: 1 }, { expireAfterSeconds: 3600 })  // 1h 后自动删

// === 8. Partial 索引(只索引部分文档,节省 50%+ 空间) ===
db.orders.createIndex(
  { user_id: 1 },
  { partialFilterExpression: { status: { $eq: "active" } } }
)

// === 9. 查看 / 删除索引 ===
db.products.getIndexes()
db.products.dropIndex("category_1")
db.products.dropIndexes()  // 删 _id 外全部,慎用

3.3 explain() 执行计划分析

// executionStats 模式:看真实耗时
db.orders.find({ status: "paid", price: { $gte: 100 } })
  .sort({ created_at: -1 }).explain("executionStats")

// 关键字段解读:
//  executionStats.executionTimeMillis    真实耗时
//  winningPlan.stage = IXSCAN            ✅ 命中索引
//  winningPlan.stage = COLLSCAN          ❌ 全表扫描
//  totalDocsExamined vs totalKeysExamined 越接近 1 越好

调研依据:MongoDB 索引官方文档(Indexes);WiredTiger 存储引擎;MongoDB 性能优化白皮书 — 复合索引遵循 ESR 法则。

4. Aggregation 聚合框架

Aggregation Pipeline 是 MongoDB 的「类 SQL 数据仓库」,管道式数据处理。

4.1 核心阶段对照

4.2 用户消费分析 5 个聚合管道

// === 管道 1:每用户消费总额(类 SQL GROUP BY) ===
db.orders.aggregate([
  { $match: { status: "paid", created_at: { $gte: ISODate("2026-01-01") } } },
  { $group: {
      _id: "$user_id",
      total_amount: { $sum: "$total" },
      order_count:  { $sum: 1 },
      avg_amount:   { $avg: "$total" },
      max_amount:   { $max: "$total" }
  }},
  { $sort: { total_amount: -1 } },
  { $limit: 100 }
])

// === 管道 2:每日订单趋势 ===
db.orders.aggregate([
  { $match: { status: "paid" } },
  { $group: {
      _id: { $dateToString: { format: "%Y-%m-%d", date: "$created_at" } },
      count: { $sum: 1 },
      gmv:   { $sum: "$total" }
  }},
  { $sort: { _id: 1 } }
])

// === 管道 3:$lookup 关联用户表(类 SQL JOIN) ===
db.orders.aggregate([
  { $match: { status: "paid" } },
  { $lookup: {
      from: "users",
      localField: "user_id",
      foreignField: "_id",
      as: "user_info"
  }},
  { $unwind: "$user_info" },
  { $project: {
      order_id: "$_id",
      user_name: "$user_info.name",
      user_city: "$user_info.city",
      total: 1
  }}
])

// === 管道 4:$unwind + 商品打平 ===
db.orders.aggregate([
  { $match: { status: "paid" } },
  { $unwind: "$items" },
  { $group: {
      _id: "$items.sku",
      qty_total: { $sum: "$items.qty" },
      revenue:   { $sum: { $multiply: ["$items.price", "$items.qty"] } }
  }},
  { $sort: { revenue: -1 } },
  { $limit: 20 }    // Top 20 SKU
])

// === 管道 5:$facet 多维度一次拿全(分页 + 统计) ===
db.products.aggregate([
  { $match: { category: "服装" } },
  { $facet: {
      "page_data": [
        { $sort: { created_at: -1 } },
        { $skip: 0 }, { $limit: 20 },
        { $project: { name: 1, price: 1, cover: 1 } }
      ],
      "stats": [
        { $group: {
            _id: null,
            total: { $sum: 1 },
            avg_price: { $avg: "$price" },
            max_price: { $max: "$price" }
        }}
      ]
  }}
])

调研依据:MongoDB Aggregation 官方文档;MongoDB 权威指南 Ch.6;阿里云 MongoDB 最佳实践。

5. 复制集(Replica Set)详解

5.1 架构

flowchart TB
    C["Client"]
    P["PRIMARY<br/>(oplog 复制)"]
    S1["SEC-1"]
    S2["SEC-2"]
    ARB["ARB<br/>(Arbiter 不存数据,只投票)"]

    C -->|"写"| P
    P --> S1
    P --> S2
    P --> ARB

5.2 选举与故障转移

• Primary 挂了 → Secondary 在 10-12 秒 内发起选举 → 票数过半的 Secondary 升 Primary
• 基于 Raft 协议 简化版 + oplog 时间戳(优先选最新的)
• 写入需 majority 确认(可调 writeConcern)

5.3 完整部署(3 节点 RS)

# 1. 启动 3 个 mongod 实例
mongod --port 27017 --dbpath /data/rs0-0 --replSet rs0 --bind_ip_all &
mongod --port 27018 --dbpath /data/rs0-1 --replSet rs0 --bind_ip_all &
mongod --port 27019 --dbpath /data/rs0-2 --replSet rs0 --bind_ip_all &

# 2. 初始化副本集
mongosh --port 27017 --eval '
  rs.initiate({
    _id: "rs0",
    members: [
      { _id: 0, host: "host1:27017" },
      { _id: 1, host: "host2:27018" },
      { _id: 2, host: "host3:27019" }
    ]
  })'

# 3. 查看状态
rs.status()
rs.isMaster()

5.4 读写分离(Python)

from pymongo import MongoClient, ReadPreference

# Primary 写,Secondary 读(读负载分摊 60-70%)
client = MongoClient(
    "mongodb://host1:27017,host2:27018,host3:27019/?replicaSet=rs0",
    readPreference=ReadPreference.SECONDARY_PREFERRED,  # 优先从 Secondary 读
    w="majority",        # 写需多数确认
    readConcernLevel="local",
    retryWrites=True
)
db = client.ecommerce

# 写走 Primary(默认)
db.orders.insert_one({...})

# 读走 Secondary
order = db.orders.find_one({"_id": oid})

5.5 真实案例

电商订单库 3 节点 RS:Primary 挂 12 秒内自动切换,前端无感知;凌晨全量备份在 Secondary 执行(db.fsyncLock()),不阻塞线上写入;按业务分库:orders(3 节点 PSS)、users(3 节点 PSS)、logs(PSS + 1 Arbiter)。

6. 分片集群(Sharded Cluster)详解

6.1 三组件架构

flowchart TB
    C["Client App"]
    M["Mongos<br/>Query Router<br/>(无状态)"]
    S0["Shard 0 (RS)<br/>存数据"]
    S1["Shard 1 (RS)<br/>存数据"]
    S2["Shard 2 (RS)<br/>存数据"]
    CS["Config Server (RS×3)<br/>存元数据 + 分片路由"]

    C --> M
    M --> S0
    M --> S1
    M --> S2
    M -.元数据.-> CS

6.2 分片键选择策略

6.3 Chunk 拆分与 Balancer

• MongoDB 把数据切成 Chunk(默认 64MB),Balancer 在后台自动迁移,使各 Shard Chunk 数量均衡。
• 触发:Chunk 超过 chunkSize 或 Shard 间 Chunk 数量差 > 阈值。

6.4 完整部署(2 Shard × RS + Config RS + 2 Mongos)

# === Step 1: Config Server (3 节点 RS) ===
mongod --port 27019 --configsvr --replSet configRS \
  --dbpath /data/cfg0 &
mongod --port 27020 --configsvr --replSet configRS \
  --dbpath /data/cfg1 &
mongod --port 27021 --configsvr --replSet configRS \
  --dbpath /data/cfg2 &
mongosh --port 27019 --eval '
  rs.initiate({_id: "configRS", members: [
    {_id: 0, host: "h1:27019"}, {_id: 1, host: "h2:27020"}, {_id: 2, host: "h3:27021"}
  ]})'

# === Step 2: Shard0 (3 节点 RS) ===
mongod --port 27017 --shardsvr --replSet shard0RS --dbpath /data/s0-0 &
# ... 类似步骤 1,初始化 shard0RS

# === Step 3: Shard1 (3 节点 RS) ===
# 同上

# === Step 4: Mongos (无状态,可多实例) ===
mongos --port 27018 --configdb configRS/h1:27019,h2:27020,h3:27021 &

# === Step 5: 添加分片 + 启用分片 ===
mongosh --port 27018 <<'EOF'
sh.addShard("shard0RS/h1:27017,h2:27017,h3:27017")
sh.addShard("shard1RS/h4:27017,h5:27017,h6:27017")
sh.enableSharding("iot")
sh.shardCollection("iot.sensor_data", { device_id: "hashed" } )  // 哈希分片
EOF

6.5 真实案例:从单库到分片支撑 100 亿文档

某 IoT 平台传感器数据 100 亿条 / 日增 5000 万:

// IoT 分片配置
sh.shardCollection("iot.sensor_data", { device_id: "hashed" } )
// TTL 自动过期
db.sensor_data.createIndex(
  { ts: 1 },
  { expireAfterSeconds: 365 * 24 * 3600 }   // 1 年自动删
)

调研依据:MongoDB Sharding 官方文档;MongoDB 权威指南 Ch.10;阿里 / 腾讯云 MongoDB 分片实践白皮书;MongoDB 性能优化白皮书。

7. Change Stream + 事务

7.1 Change Stream(CDC 数据变更捕获)

Change Stream 基于 oplog tail,实时推送集合变更事件(insert/update/delete/replace),是 MongoDB 4.0+ 官方 CDC 方案。

from pymongo import MongoClient

client = MongoClient("mongodb://host1:27017/?replicaSet=rs0")
db = client.ecommerce

# 监听 orders 集合变更
pipeline = [
    {"$match": {"operationType": {"$in": ["insert", "update"]},
                "fullDocument.status": "paid"}}
]

try:
    with db.orders.watch(pipeline, full_document="updateLookup") as stream:
        for change in stream:
            print(f"事件:{change['operationType']}, 订单:{change['fullDocument']['_id']}")
            # 推送下游:ES 索引 / 缓存 / 推荐系统
            process_event(change)
except OperationFailure as e:
    if e.code == 286:  # resume token 失效
        resume_token = load_last_token()  # 从持久化存储恢复
        stream = db.orders.watch(pipeline, resume_after=resume_token)

断点续传:Change Stream 通过 _id(resume token)实现 exactly-once,务必把 token 持久化(Redis/DB),否则 OOM/重启会丢事件。

7.2 多文档事务(MongoDB 4.0+)

from pymongo import MongoClient

client = MongoClient("mongodb://host1:27017/?replicaSet=rs0")
client.admin.command("ping")

# 转账事务:扣 A 加 B,要么都成要么都败
with client.start_session() as session:
    with session.start_transaction():
        db = client.bank
        db.accounts.update_one(
            {"_id": "A", "balance": {"$gte": 100}},
            {"$inc": {"balance": -100}},
            session=session
        )
        db.accounts.update_one(
            {"_id": "B"},
            {"$inc": {"balance": 100}},
            session=session
        )
        # session.end_transaction() 自动在 with 退出时调用
# 异常会自动 abort_transaction

7.3 Change Stream vs Debezium 对比

8. 实战案例 4 个

8.1 案例 1:电商商品中心(SPU/SKU 嵌套 + 多规格)

背景:某垂直电商 5 万 SPU、200 万 SKU,商品属性差异极大(服装有尺码、3C 有配置、图书有作者)。

设计:SPU + 嵌套 SKU 数组 + attrs 灵活属性桶。{spu: 1} 做复合索引(类目+SPU),{name: "text"} 做全文搜索,{specs.sku: 1} unique 做库存查询路由。

收益:商品详情页从 MySQL 7 次 JOIN → MongoDB 单次查询,RT 由 80ms 降至 8ms;新增「自定义属性」零迁移。

8.2 案例 2:物联网时序数据(100 亿 + 分片 + TTL)

背景:智能工厂 50 万设备,每秒上报 5 个指标(ts/temp/vibration/…),日增量 5000 万条。

设计:{device_id: "hashed"} 分片键(写均匀),{device_id:1, ts:-1} 复合索引(查设备历史),TTL 索引保留 1 年热数据 + 冷数据归档到 OSS。WiredTiger 压缩比 5:1,磁盘占用从预估 30TB 降至 6TB。

收益:写入 TPS 8 万/秒(单 shard),扩容到 4 shard 32 万/秒;查询近 24h 数据 < 100ms。

8.3 案例 3:MySQL 迁移 MongoDB(社交 Feed 流 + 评论树)

背景:某社区 App 从 MySQL 迁 MongoDB。MySQL 5 张表(feed/comment/like/repost/mention),Feed 查询 4 次 JOIN,P99 1.2s。

设计:把 feed + 评论树 + 互动计数器嵌入单文档,{author_id:1, created_at:-1} 索引个人主页,{tags:"multikey", created_at:-1} 索引话题页。评论树用 parent_id 引用 + 一次 $graphLookup 递归拉全树。

收益:Feed 列表 P99 从 1.2s → 35ms;评论加载从 800ms → 50ms;DB 节点从 8 主 16 从缩到 3 Shard × 3 节点。

8.4 案例 4:Change Stream 构建实时推荐系统

背景:电商需「用户下单 5 秒内」推送关联商品到首页,要求近实时。

架构:订单 collection → Change Stream → 流处理(Spark/Flink 轻量级)→ 用户画像更新 → 推荐引擎(ES)→ WebSocket 推送。

关键:Change Stream full_document="updateLookup" 保证拿到完整快照;resume token 存 Redis 持久化;消费者幂等用订单 _id 去重。

收益:推荐延迟从 T+1(批处理)→ < 3 秒,CTR 提升 22%。

9. 选型决策树 + 踩坑 6 个

9.1 5 维度选型决策树

flowchart TD
    Q{"数据规模 ≥ 10 亿/单表?"}
    Q -->|"Yes"| A{"是否需要水平扩展?"}
    Q -->|"No"| C{"查询模式:聚合/全文/地理?"}

    A -->|"Yes"| B{"单分片是否够?"}
    A -->|"No"| C

    B -->|"Yes"| R1["MongoDB RS"]
    B -->|"No"| R2["MongoDB Sharded"]

    C -->|"Yes"| T{"强事务 < 3 表?"}
    C -->|"No"| E["ES/其他"]

    T -->|"Yes"| S1["MongoDB 独立"]
    T -->|"No"| S2["PostgreSQL"]

    R1 --> C
    R2 --> C

9.2 5 维度对比表

9.3 选型口诀 3 句话

JSON 海量选 Mongo,严格事务选 PG/MySQL,聚合复杂选 Mongo + Pipeline。 小规模别上分片,3 节点 RS 起步,10 亿文档再分片。 强事务不过 3 表,读多写少可冗余,索引永远走 ESR。

9.4 踩坑 6 个

坑 1:文档无限增长(超 16MB BSON 限制)

• 症状:BSONObj size: 16777208 is invalid,写入失败。
• 原因:评论/日志无限追加到数组,单文档超 16MB 硬上限。
• 修法:改 Bucket Pattern —— 按 parent_id + page_no 拆子集合;或 GridFS 存大对象。
• 命令:

  db.posts.updateMany({}, { $unset: { "old_comments": "" } })  // 清理旧数据
  // 新设计:按 page 分桶
  db.posts.createIndex({ parent_id: 1, page_no: 1 }, { unique: true })
  

坑 2:索引没建(COLLSCAN)

• 症状:db.orders.find({user_id: u001}) 慢,P99 2s。
• 原因:user_id 字段无索引,百万级数据全表扫描。
• 修法:建索引 + explain 验证走 IXSCAN。
• 命令:

  db.orders.createIndex({ user_id: 1 })
  db.orders.find({ user_id: "u001" }).explain("executionStats")
  // winningPlan.stage 应为 IXSCAN,非 COLLSCAN
  

坑 3:分片键选错(单调递增 = 热分片)

• 症状:3 个 Shard 数据分布 95%/3%/2%,写都打 Shard0。
• 原因:用 ObjectId/created_at 做范围分片,新数据永远写最新 Chunk。
• 修法:改 hashed 分片 或 复合分片(如 {customer_id: "hashed", created_at: 1})。
• 命令:

  // 4.4+ 支持修改分片键(需 reshardCollection)
  db.adminCommand({
  reshardCollection: "iot.sensor_data",
  key: { device_id: "hashed" }
  })
  

坑 4:大量 $lookup(性能差)

• 症状:聚合管道 3 次 $lookup,P99 1.5s。
• 原因:跨集合关联需要读取所有匹配文档,内存+网络开销大。
• 修法:能 Embed 就 Embed;不能 Embed 就在写入时 冗余 关键字段(如订单存 user_name 快照);实在要 Lookup 加索引 + $lookup 用 pipeline 模式提前过滤。
• 命令:

  // 冗余写入:order 创建时快照 user 信息
  db.orders.insertOne({
  user_id: u001,
  user_name_snapshot: "张三",     // 冗余,避免后续 Lookup
  ...
  })
  

坑 5:Change Stream resume token 丢失

• 症状:消费者重启后报 ChangeStreamHistoryLost,事件从 0 开始重复。
• 原因:resume token 没持久化;oplog 被覆盖(默认 5GB 滚动);消费者代码没用 try/except。
• 修法:token 实时存 Redis;oplog 调大 --oplogSize;监听 change_stream_history_lost 告警 + 从业务时间戳对账。
• 命令:

  mongod --oplogSize 10240  # oplog 调大到 10GB
  

  # 持久化 token
  token = change["_id"]
  redis.set("cs:orders:last_token", bson.encode(token), ex=86400)
  

坑 6:事务滥用(多文档事务性能差)

• 症状:事务内 8 次写,TPS 从 8000 降到 200,锁等待严重。
• 原因:多文档事务需 majority 写 + 锁协调,代价高;MongoDB 事务不是万能胶水。
• 修法:重新设计数据模型避免事务 —— Embed 相关文档到同一 collection;或幂等补偿(失败重试);单文档事务 永远 OK,多文档谨慎。
• 命令:

  // ❌ 错误:多文档事务跨 3 个 collection
  session.with_transaction(() => {
  db.orders.insertOne({...})
  db.inventory.updateOne({...})
  db.logs.insertOne({...})
  })
  // ✅ 正确:Embed 到同一文档,事务消失
  db.orders.insertOne({
  items: [...],       // 内嵌订单详情
  inventory_log: [...], // 内嵌库存流水
  })
  

附录 A:索引策略速查表

附录 B:分片键选择速查表

附录 C:MongoDB 性能 Checklist 12 项

1. ☐ 所有查询字段建索引,explain 验证走 IXSCAN
2. ☐ 复合索引遵循 ESR 法则(Equality→Sort→Range)
3. ☐ 单文档 ≤ 16MB,避免数组无限增长
4. ☐ 业务高峰期前 1h analyze + 监控 collscan 计数
5. ☐ Replica Set 写 majority 确认,读 secondaryPreferred
6. ☐ 单分片扛不住再分片,先优化 schema + 索引
7. ☐ 哈希分片键防热分片;范围分片预 split Chunk
8. ☐ TTL 索引清理过期数据,避免 collection 无限增长
9. ☐ WiredTiger 调 cacheSizeGB(默认 50% RAM)
10. ☐ Change Stream resume token 持久化到 Redis
11. ☐ 多文档事务避免跨 collection,优先 Embed
12. ☐ 监控指标:oplog window(应 > 24h)、connections、wiredTiger.cache

附录 D:复制集故障排查 Checklist

自检报告