本文共 2375 字，大约阅读时间需要 7 分钟。

MongoDB 索引与高可用性

MongoDB 索引概述

MongoDB 的索引机制与传统关系型数据库类似，旨在提升查询效率。索引可以帮助 MongoDB 通过限制文档扫描范围、快速定位所需数据来加快查询速度。此外，索引还支持排序操作，进一步优化查询结果的返回。

索引的使用代价

虽然索引能够显著缩短查询时间，但建立和维护索引也会消耗资源。尤其在高并发写入场景下，索引的更新会对性能产生负面影响。因此，在读操作少或不考虑读性能优化的情况下，建议避免过度使用索引。

MongoDB 索引类型

MongoDB 支持多种索引类型，每种类型适用于不同的场景：

1. 单字段索引

建立在单个字段上的索引，无需指定排序顺序，MongoDB 会自动选择优化的遍历路径。

2. 复合索引

复合索引由多个字段组成，按字段顺序进行排序。例如，索引 {userid: 1, score: -1} 会先按 userid 升序排序，接着在每个 userid 内按 score 降序排序。

3. 多键索引

适用于数组字段，MongoDB 为数组中的每个值创建索引，便于按数组元素值进行查询。

4. 哈希索引

基于哈希值的索引，通常用于哈希分片集群，提升查询性能。

5. 文本索引

支持对字符串内容进行全文搜索，覆盖多个字段，但性能相对较低，建议谨慎使用。

6. 地理位置索引

基于经纬度的索引，适合进行2D或3D地理位置查询。

7. 唯一索引

确保索引字段不存储重复值，避免文档中该字段出现冲突。

8. TTL 索引

TTL（Time To Live）索引为文档设置过期时间，当达到指定时间后，文档会自动删除。适用于需要数据临时存储的场景。

复合索引的字段顺序

复合索引的字段顺序对查询性能有直接影响。例如，索引 {userid: 1, score: -1} 会优先按 userid 升序排序，再按 score 降序排序。字段顺序决定了查询时的索引使用情况。

示例

以下查询会使用复合索引：

db.s2.find().sort({ "userid": 1, "score": -1})

而以下查询则不会使用：

db.s2.find().sort({ "userid": 1, "score": 1})

通过 explain 分析查询执行计划，可以进一步了解索引的使用情况。

TTL 索引详解

TTL 索引提供了文档过期机制，允许为每个文档指定过期时间 expireAfterSeconds。当文档达到过期时间后，会被自动删除。

TTL 索引特点

• 过期机制：MongoDB 后台线程定期检查文档是否过期，删除已过期的文档。
• 副本集支持：从节点的数据删除由主库的 oplog 同步完成。
• 限制条件：
  • TTL 索引为单字段索引，不能用于复合索引。
  • _id 字段不支持 TTL 索引。
  • 上限集合（Capped Collection）不支持 TTL 索引。
  • 已有非 TTL 索引的字段无法再创建 TTL 索引。

TTL 索引的应用场景

TTL 索引适用于需要数据临时存储的场景，如日志、事件数据等，确保数据在一定时间内自动清理。

覆盖索引查询

覆盖查询是指所有查询字段都是索引的一部分，并且结果字段也在同一索引中。此外，查询条件不能为 null。

示例

例如，创建联合索引 gender: 1, user_name: 1，查询 db.users.find({gender: "M"}, {user_name: 1, _id: 0}) 会覆盖该索引。

注意事项

要确保查询字段均属于索引字段，且结果字段也在索引范围内。如果需要排除 _id 字段，需显式指定 _id: 0。

MongoDB 高可用性

复制集群

复制集群（副本集）由主节点和从节点组成，主节点负责写操作，从节点负责读操作，确保集群在主节点故障时自动恢复。

复制集群结构

• 主节点（Primary）：接收所有写操作，负责数据同步。
• 从节点（Secondary）：负责读操作，主故障时可自动选举新主节点。
• 仲裁节点（Arbiter）：参与主节点选举，确保选举过程的多数认可。

数据同步机制

主节点将写操作记录到 oplog 上限集合，From节点通过拉取 oplog 进行数据同步。

复制集群的优势

• 故障恢复：主节点故障时，自动从从节点选举新主节点。
• 读写分离：主节点专注于写操作，从节点处理读操作，减轻主节点压力。

分片集群

分片集群（Sharding）通过将数据分布到多个分片（Shard）中，解决副本集的性能瓶颈问题。

分片集群结构

• 配置服务器（Config Server）：存储分片配置，如分片地址和分块信息。
• 路由节点（Mongos）：接收请求并转发到目标分片。
• 分片（Shard）：存储数据的子集，通常部署为副本集架构。

分片键选择

分片键决定数据分布的方式，需考虑取值基数、分布均匀性、查询特性和避免单调序列等因素。

分片策略

• 基于范围的分片：适合范围查询和较大基数的分片键。
• 基于哈希的分片：适合随机查询和较小基数的分片键。
• 复合分片键：结合低基数和单调序列字段。

分片数据存储

分片集群通过 Chunk 实现数据存储，Chunk 是逻辑数据单元，按分片键范围划分数据。默认 Chunk 大小为 64MB，可自定义。

Chunk 分裂与迁移

• Chunk 分裂：插入或更新操作可能导致 Chunk 分裂。
• Chunk 迁移：Balancer 组件自动平衡 Chunk 分布，确保各分片负载均衡。

总结

MongoDB 的索引和高可用性机制为用户提供了强大的数据管理能力。合理使用索引可以显著提升查询性能，而分片集群则能够应对大规模数据和高并发访问的挑战。理解和优化这些机制对于构建高性能 MongoDB 应用至关重要。