Simi Studio
文章 标签 分类
Simi Studio

目录

MongoDB 索引最佳实践

 收录于 数据库
   约 3780 字   预计阅读 8 分钟 

在 MongoDB 数据库管理中，索引是决定查询性能的关键因素。正确的索引策略能够将查询响应时间从秒级降低到毫秒级，而索引的缺失或不当设计则可能导致数据库成为系统性能瓶颈，尤其是在数据量达到百万级以上时。

1. 环境搭建：容器化的 MongoDB 开发环境

为了进行性能测试，需要一个稳定且隔离的 MongoDB 环境。以下配置使用 Docker Compose 启动一个 MongoDB 实例以及一个用于数据可视化管理的 Mongo Express 服务。

首先，在项目根目录创建 .env 文件，用于存放敏感配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# MongoDB Configuration
MONGO_ROOT_USERNAME=root
MONGO_ROOT_PASSWORD=your-strong-root-password
MONGO_PORT=27017

# Mongo Express Configuration
MONGO_EXPRESS_PORT=8081
MONGO_EXPRESS_BASICAUTH_ENABLED=true
MONGO_EXPRESS_USERNAME=mongoexpressuser
MONGO_EXPRESS_PASSWORD=your-express-password

接着，创建 docker-compose.yml 文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

version: "3.9"

services:
  mongo:
    image: mongo:8.0.13  # Using a recent stable version
    container_name: mongodb_indexing_practice
    restart: unless-stopped
    environment:
      MONGO_INITDB_ROOT_USERNAME: ${MONGO_ROOT_USERNAME:-root}
      MONGO_INITDB_ROOT_PASSWORD: ${MONGO_ROOT_PASSWORD:-example}
    ports:
      - "${MONGO_PORT:-27017}:27017"
    volumes:
      - mongodb_data:/data/db
    networks:
      - mongodb-network
    healthcheck:
      test: ["CMD", "mongosh", "--quiet", "--eval", "db.adminCommand('ping')"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

  mongo-express:
    image: mongo-express
    container_name: mongo-express
    restart: unless-stopped
    ports:
      - "${MONGO_EXPRESS_PORT:-8081}:8081"
    environment:
      ME_CONFIG_MONGODB_URL: mongodb://${MONGO_ROOT_USERNAME:-root}:${MONGO_ROOT_PASSWORD:-example}@mongo:27017/
      ME_CONFIG_BASICAUTH_ENABLED: ${MONGO_EXPRESS_BASICAUTH_ENABLED:-true}
      ME_CONFIG_BASICAUTH_USERNAME: ${MONGO_EXPRESS_USERNAME:-mongoexpressuser}
      ME_CONFIG_BASICAUTH_PASSWORD: ${MONGO_EXPRESS_PASSWORD:-mongoexpresspass}
    networks:
      - mongodb-network
    depends_on:
      mongo:
        condition: service_healthy

volumes:
  mongodb_data:
    driver: local

networks:
  mongodb-network:
    driver: bridge

启动服务： 在终端中执行以下命令启动所有服务。

1

docker compose up -d

连接到 MongoDB Shell (mongosh)： 使用以下命令连接到正在运行的 MongoDB 容器。请将 your-strong-root-password 替换为 .env 文件中设置的密码。

1

docker exec -it mongodb_indexing_practice mongosh -u root -p 'your-strong-root-password'

连接成功后，即可开始后续的数据操作和性能测试。

2. 模拟真实工作负载：生成百万级数据集

为了有效评估索引性能，需要一个大规模的数据集。以下脚本将模拟一个电商或内容平台的场景，生成一百万条包含状态、类别、创建时间和评分等字段的文档。

在 mongosh 中执行以下脚本：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

use benchdb;
db.events.drop();

const statuses = ["active", "inactive", "pending"];
const categories = ["A", "B", "C", "D", "E", "F", "G", "H"];
const total = 1_000_000;
const batchSize = 5000;
console.log(`开始生成 ${total} 条测试数据...`);

for (let i = 0; i < total; i += batchSize) {
    let bulkOps = [];
    for (let j = 0; j < batchSize; j++) {
        const docIndex = i + j;
        if (docIndex >= total) break;

        bulkOps.push({
            insertOne: {
                document: {
                    status: statuses[docIndex % statuses.length],
                    category: categories[docIndex % categories.length],
                    createdAt: new Date(Date.now() - Math.floor(Math.random() * 365 * 86400000)), // 过去一年内的随机时间
                    score: NumberInt(Math.floor(Math.random() * 100000)),
                    name: `Product-${docIndex}`,
                    payload: { data: "..." } // 模拟其他业务数据
                }
            }
        });
    }
    if (bulkOps.length > 0) {
        db.events.bulkWrite(bulkOps, { ordered: false });
    }
    if ((i + batchSize) % 100000 === 0) {
        console.log(`已插入 ${Math.min(i + batchSize, total)} 条...`);
    }
}

console.log(`数据生成完毕！集合中总文档数: ${db.events.countDocuments()}`);

注意： 在进行大规模数据导入时，应先导入数据，再创建索引。如果在导入过程中已存在索引，每次插入操作都会触发索引更新，从而显著降低写入性能。

3. 从集合扫描到索引扫描：性能分析与优化

本节将分析一个典型的多条件查询在有无索引情况下的性能表现。查询需求为：查找状态为 “active”、类别为 ‘A’ 或 ‘B’、创建时间在最近 90 天内，并按分数倒序排列的前 10 个文档。

3.1. 性能基线：COLLSCAN 带来的性能瓶颈

在没有任何索引的情况下，执行查询并使用 explain("executionStats") 来分析其执行计划。

1
2
3
4
5
6
7

const ninetyDaysAgo = new Date(Date.now() - 90 * 86400000);

db.events.find({
    status: "active",
    category: { $in: ["A", "B"] },
    createdAt: { $gte: ninetyDaysAgo }
}).sort({ score: -1 }).limit(10).explain("executionStats");

执行计划关键指标分析：

1
2
3
4
5
6
7
8

"executionStats": {
    "executionSuccess": true,
    "nReturned": 10,
    "executionTimeMillis": 850, // 执行时间，可能因硬件而异
    "totalKeysExamined": 0,
    "totalDocsExamined": 1000000, // 扫描了集合中的全部文档
    "stage": "COLLSCAN" // 执行阶段为全集合扫描
}
  • stage: "COLLSCAN": 这是性能低下的根源。MongoDB 必须遍历集合中的每一个文档，以检查其是否满足查询条件。
  • totalDocsExamined: 1000000: 该数值等于集合总文档数，是 COLLSCAN 的直接证据。
  • executionTimeMillis: 在百万级数据量下，执行时间通常在数百毫秒到数秒之间，对高并发应用而言是不可接受的延迟。

3.2. ESR 规则：复合索引设计的核心原则

为了优化此查询，需要创建一个复合索引。复合索引的字段顺序至关重要，应遵循 ESR (Equality, Sort, Range) 规则：

  1. E (Equality): 索引的前缀字段应为等值查询（如 status: "active"）和多值等值查询（如 category: { $in: [...] }）所使用的字段。其中，选择性（Cardinality）高的字段应优先放置。
  2. S (Sort): 接下来是用于排序的字段（如 sort({ score: -1 })）。索引的排序方向必须与查询的排序方向完全匹配（同为升序或同为降序）。
  3. R (Range): 最后是用于范围查询的字段（如 createdAt: { $gte: ... }）。

一旦查询优化器在索引扫描中使用了范围查询，该范围字段之后的索引字段将无法再用于满足排序需求。因此，排序字段必须置于范围字段之前。根据 ESR 规则，此查询的最佳索引为 { status: 1, category: 1, score: -1, createdAt: 1 }。

创建索引：

1

db.events.createIndex({ status: 1, category: 1, score: -1, createdAt: 1 });

3.3. 性能优化：IXSCAN 带来的显著提升

创建索引后，重新执行相同的查询与 explain()：

1
2
3
4
5

db.events.find({
    status: "active",
    category: { $in: ["A", "B"] },
    createdAt: { $gte: ninetyDaysAgo }
}).sort({ score: -1 }).limit(10).explain("executionStats");

优化后的执行计划关键指标：

1
2
3
4
5
6
7
8

"executionStats": {
    "executionSuccess": true,
    "nReturned": 10,
    "executionTimeMillis": 2, // 执行时间大幅缩短
    "totalKeysExamined": 2500, // 仅检查了少量索引键
    "totalDocsExamined": 2500, // 仅加载了少量文档
    "stage": "IXSCAN" // 执行阶段为索引扫描
}
  • stage: "IXSCAN": 查询计划成功转为索引扫描，表明 MongoDB 有效地利用了新创建的索引。
  • totalKeysExamined 和 totalDocsExamined 急剧下降。MongoDB 通过索引快速定位到满足 status 和 category 条件的索引条目，并利用索引的 score 排序，高效地筛选出满足 createdAt 条件的文档。
  • executionTimeMillis: 执行时间从 850ms 降至 2ms，性能提升超过 400 倍。

3.4. 极致性能：覆盖查询（Covered Query）

尽管 IXSCAN 已经非常高效，但 MongoDB 在通过索引找到文档后，仍需根据索引中的指针返回磁盘读取完整的文档（此过程称为回表或 FETCH）。如果查询所需的所有字段（包括查询条件和投影字段）都已包含在索引中，MongoDB 则可以直接从内存中的索引返回结果，无需读取磁盘上的文档。这就是覆盖查询，是索引性能的理想状态。

为实现覆盖查询，需要创建一个包含查询所需所有字段的索引，并在查询时使用投影（projection）来指定只返回这些字段。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 创建一个能覆盖查询的索引，额外包含 name 字段
db.events.createIndex({ status: 1, category: 1, score: -1, createdAt: 1, name: 1 });

// 执行只请求索引内字段的查询
db.events.find(
    {
        status: "active",
        category: { $in: ["A", "B"] },
        createdAt: { $gte: ninetyDaysAgo }
    },
    { _id: 0, status: 1, category: 1, score: 1, createdAt: 1, name: 1 } // 投影
).sort({ score: -1 }).limit(10).explain("executionStats");

在分析 explain 结果时，判断是否为覆盖查询的关键指标是：

  1. executionStats.totalDocsExamined 值为 0。
  2. 执行计划中没有 FETCH 阶段。

注意：关于现代查询计划的解读

在现代 MongoDB 版本中，针对包含 $in 操作符的查询，优化器可能会选择一个更高级的 SORT_MERGE 计划。它会将 $in 查询分解为多个并行的 IXSCAN，然后将各自有序的结果高效合并。

此时，您看到的执行计划可能类似于 LIMIT -> PROJECTION_DEFAULT -> SORT_MERGE -> (多个 IXSCAN)。这并不意味着查询失败。恰恰相反，这表明优化器找到了一个更快的执行路径。只要 totalDocsExamined 仍然为 0 并且没有 FETCH 阶段，它就是一个非常高效的、成功的覆盖查询。这证明了即使在复杂的查询计划中，覆盖查询的性能优势依然存在。

4. 专业诊断与管理常用命令

在复杂的生产环境中，主动发现、诊断和管理索引至关重要。

4.1. Database Profiler: 数据库性能探针

Profiler 是一个用于捕获慢查询的内置工具，能够记录超过指定阈值的数据库操作。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// 开启 Profiler，记录所有耗时超过 30ms 的操作
db.setProfilingLevel(1, { slowms: 30 });

// ... 运行应用程序以产生查询负载 ...

// 查询慢查询日志，按时间倒序排列
db.system.profile.find().sort({ ts: -1 }).limit(5).pretty();

// 关闭 Profiler
db.setProfilingLevel(0);

// 检查当前 Profiler 状态
db.getProfilingStatus();

通过分析 system.profile 集合中的文档，可以精确识别生产环境中的性能瓶颈及其查询模式，为索引优化提供依据。

4.2. $indexStats: 索引健康检查器

该聚合阶段可以返回每个索引的使用频率统计。

1

db.events.aggregate([{ $indexStats: {} }]).pretty();

定期执行此命令。如果一个索引的 ops 字段长期为 0，表明该索引未被任何查询使用，可以考虑将其删除，以减少写操作的开销和存储空间的占用。

4.3. 索引管理常用命令

掌握核心的索引管理命令是日常维护的基础。

  • 创建索引 (createIndex) 用于在集合上创建一个新索引。

    1
2
3

    // 语法: db.collection.createIndex( <keys>, <options> )
// 创建一个后台运行的唯一索引
db.events.createIndex({ name: 1 }, { unique: true, background: true });

    background: true 选项非常重要，它能让索引在后台构建，避免阻塞生产环境的其他数据库操作。

  • 查看索引 (getIndexes) 列出集合上的所有索引及其详细信息。

    1

    db.events.getIndexes();

    这是检查现有索引配置、获取索引名称以便进行删除或隐藏操作的第一步。

  • 删除索引 (dropIndex) 用于移除不再需要的索引。可以通过索引名称或键模式来指定要删除的索引。

    1
2
3
4
5

    // 按名称删除（推荐方式）
db.events.dropIndex("status_1_category_1_score_-1_createdAt_1");

// 按键模式删除
db.events.dropIndex({ status: 1, category: 1, score: -1, createdAt: 1 });

  • 隐藏与恢复索引 (hideIndex / unhideIndex) 在不确定是否可以删除某个索引时，可以先将其隐藏，使其对查询优化器不可见，从而安全地评估其影响。

    1
2
3
4
5
6
7

    // 隐藏索引
db.events.hideIndex("status_1_category_1_score_-1_createdAt_1_name_1");

// ... 在此期间进行性能测试 ...

// 恢复索引
db.events.unhideIndex("status_1_category_1_score_-1_createdAt_1_name_1");

4.4. 系统化的优化工作流

  1. 捕获: 使用 Profiler 发现慢查询。
  2. 分析: 使用 explain() 复现问题，确认是否存在 COLLSCAN 或低效 IXSCAN。
  3. 设计: 根据 ESR 规则设计或调整索引。
  4. 验证: 再次使用 explain() 验证查询计划已优化，并确认 executionTimeMillis 和 totalKeysExamined 等指标显著改善。
  5. 监控: 通过 $indexStats 持续监控索引使用情况，定期使用 dropIndex 或 hideIndex 清理未使用的索引。

5. 其他索引类型概览

除复合索引外，MongoDB 还提供多种专用索引以满足不同场景的需求。

  • 文本索引 ("text"): 专为全文搜索设计，支持语言分词和相关性排序。
  • 地理空间索引 ("2dsphere"): 用于处理地理位置数据，支持基于点、线和多边形的查询。
  • 部分索引 (Partial Indexes): 只对集合中满足特定筛选条件的文档创建索引。例如，可以仅为状态为 archived 的文档创建索引，从而大幅减少索引大小和维护成本。

6. 索引最佳实践清单

  1. 为查询而设计索引: 索引应服务于应用中最频繁、性能最关键的查询，而非盲目地为集合中的每个字段创建单字段索引。
  2. 严格遵循 ESR 规则: 对于复合索引，等值(E) → 排序(S) → 范围(R) 的字段顺序是确保性能的关键。将最具选择性的等值过滤字段置于索引前缀。
  3. 将 explain() 作为核心工具: 在创建或修改索引前后，务必使用 explain() 来验证查询计划是否符合预期，确保查询能够高效利用索引。
  4. 优先考虑覆盖查询: 在可能的情况下，设计索引以包含查询和投影所需的所有字段，以避免磁盘 I/O，实现最佳查询性能。
  5. 理解索引的成本: 每个索引都会占用存储空间和内存，并增加写操作（insert, update, delete）的开销。应仅创建必要的索引，并定期使用 $indexStats 清理冗余索引。
  6. 持续监控与迭代: 数据库性能是一个动态过程。应使用 Profiler 等工具持续监控，并根据业务需求和查询模式的变化，适时调整索引策略。
更新于 2025-09-18
 Database, MongoDB
返回 | 主页