MongoDB 索引与事务

索引与优化

1.1 索引类型

每个集合默认在 _id 字段上有一个唯一索引。

//  个人最常用的是单字段索引、复合索引、后台建立索引、查询集合索引
db.user.createIndex({ name: 1 })
db.user.createIndex({ name: 1, age: -1 })                                   // 复合
db.user.createIndex({ name: 1 }, { unique: true })                           // 唯一
db.user.createIndex({ email: 1 }, { unique: true, sparse: true })            // 稀疏
db.user.createIndex({ age: 1 }, { partialFilterExpression: { age: { $gt: 18 } } }) // 部分
db.user.createIndex({ createTime: 1 }, { expireAfterSeconds: 3600 })         // TTL
db.user.createIndex({ desc: "text" })                                        // 文本
db.user.createIndex({ loc: "2dsphere" })                                     // 地理
db.user.createIndex({ shardKey: "hashed" })                                  // 哈希
db.users.createIndex({ age: 1 }, { background: true }) // 后台建立索引（避免生产环境读写被阻塞）
db.user.getIndexes()  
db.user.dropIndex("name_1")

1.2 索引核心规则

1.3 与 MySQL 索引对比

1.4 慢查询定位

// 有阿里云服务器的，可查询MongoDB慢SQL日志
// 1. 开启慢查询采集（慢于 100ms 记录到 system.profile）
db.setProfilingLevel(1, { slowms: 100 })
db.system.profile.find().sort({ ts: -1 }).limit(10)

// 2. 执行计划分析
db.user.find({ age: { $gt: 18 } }).explain("executionStats")

看三个关键值：

• stage：COLLSCAN 全表扫描（要警惕） / IXSCAN 走索引（正常）
• totalDocsExamined 与 nReturned：比值应接近 1，差得越多说明索引选择性越差
• executionTimeMillis：实际耗时

辅助工具：mongostat（整体吞吐）、mongotop（各集合读写耗时）、db.currentOp()（当前操作）。

1.5 TTL / 稀疏 / 部分索引的坑

• TTL 索引基于 Date 字段 + expireAfterSeconds；后台线程每 60 秒扫一次，删除时间不精确；被 TTL 删除的文档同样会产生 oplog
• 稀疏索引只跳过「完全没有该字段」的文档，字段值为 null 仍会被索引
• 部分索引用 partialFilterExpression，表达力更强，优先选部分索引

1.6 性能优化

1. 为高频查询字段建索引，尤其是 where、sort、join 用到的字段。
2. 复合索引字段顺序：等值查询在前，范围查询在后，排序字段最后。
3. 避免过多索引：每个索引都会降低写入速度，增加存储。
4. 使用覆盖查询：尽量让查询字段和返回字段都包含在索引中。
5. 使用部分索引：只索引常用子集，减少索引大小。
6. 使用 TTL 索引：自动清理过期数据。
7. 定期分析慢查询：开启 profiling，用 explain 诊断。
8. 避免在索引字段上使用 $ne、$not、$regex（非前缀），这些通常导致全表扫描。

事务与一致性

一、事务基础概念

1.1 什么是事务

事务是一组操作的集合，这些操作要么全部成功，要么全部失败，保证数据的一致性。

1.2 MongoDB 事务的发展

1.3 与关系型数据库的对比

const session = db.getMongo().startSession();
session.startTransaction();
try {
  session.getDatabase("app").orders.updateOne({ _id: 1 }, { $set: { status: "PAID" } });
  session.getDatabase("app").stock.updateOne({ sku: "A" }, { $inc: { qty: -1 } });
  session.commitTransaction();
} catch (e) {
  session.abortTransaction();
}

二、单文档原子性

2.1 核心原则

单文档原子性：MongoDB 对单个文档的更新天然原子（含嵌套子文档、数组），很多「伪事务」场景其实一条 updateOne 就能解决，不必上事务。

2.3 与多文档事务的关系

• 单文档原子性不需要显式事务，MongoDB 自动保证。
• 多文档事务只在需要跨文档、跨集合、跨分片时使用。

三、多文档事务

3.1 使用场景

• 跨集合操作（如订单和库存）
• 跨文档操作（如转账）
• 跨分片操作（分片集群）

3.2 基本语法

const session = db.getMongo().startSession();
session.startTransaction({
  readConcern: { level: "snapshot" },
  writeConcern: { w: "majority" }
});

try {
  const orders = session.getDatabase("shop").orders;
  const inventory = session.getDatabase("shop").inventory;

  orders.updateOne({ _id: 1 }, { $set: { status: "confirmed" } });
  inventory.updateOne({ sku: "A001" }, { $inc: { stock: -1 } });

  session.commitTransaction();
} catch (error) {
  session.abortTransaction();
  throw error;
} finally {
  session.endSession();
}

3.3 读关注（readConcern）

决定读取操作能看到什么样的数据
控制读的时候，数据需要被多少个节点确认，或者是否需要一致性快照

3.4 写关注（writeConcern）

写操作需要被确认到什么程度，才返回成功
控制写操作 要写到多少个节点、是否要落盘，才算成功

四、ACID 特性

五、使用限制与注意事项

5.1 限制

• 事务超时：默认 60 秒，可调整 transactionLifetimeLimitSeconds。
• 文档大小：事务中所有操作的总大小不能超过 16MB（oplog 限制）。
• 不支持的操作：
  • 创建或删除集合（4.4 之前）
  • 创建或删除索引（4.4 之前）
  • count 命令（可使用 countDocuments）
  • distinct 命令
  • 某些管理命令
• 分片集群：跨分片事务性能开销大，需谨慎使用。
• 写冲突：事务内写冲突会导致事务中止，应用需重试。

5.2 性能开销

• 多文档事务比单文档操作慢，因为需要协调多个节点、维护快照、写 oplog。
• 事务越长，持有锁和资源越久，冲突概率越高。
• 建议事务尽量短小，避免长时间运行。

5.3 重试机制

// 事务因写冲突中止时，应用层应重试
function runTransactionWithRetry(session, txnFunc) {
  while (true) {
    try {
      session.startTransaction();
      txnFunc(session);
      session.commitTransaction();
      break;
    } catch (error) {
      session.abortTransaction();
      if (error.hasErrorLabel("TransientTransactionError")) {
        continue; // 重试
      }
      throw error;
    }
  }
}