MongoDB 生产实践：索引、复制集、分片与慢查询治理

MongoDB 很容易上手，也很容易在生产环境里被误用。文档灵活、查询表达力强、开发效率高，是它的优势；但索引失控、文档膨胀、慢查询、分片键错误和复制延迟，也会让系统在增长后变得难以维护。

生产级 MongoDB 需要同时关注数据模型、索引、复制集、分片、备份和监控。不要把 MongoDB 当成“可以随便存 JSON 的地方”。

文档模型

MongoDB 的文档模型适合把强关联、一起读取、规模有限的数据放在同一个文档中。例如订单主信息和下单时的地址快照可以在一个文档里，避免每次查询订单详情都做多次关联。

但不要把无限增长数组塞进文档。例如用户所有消息、帖子所有评论、设备所有日志都不适合放进单个文档。文档过大会影响读写性能，也会遇到大小限制。

建议为文档设计明确边界：

• 文档是否会无限增长。
• 更新是否集中在同一字段。
• 查询是否总是读取整个文档。
• 是否需要对子元素单独分页。

索引设计

MongoDB 没有合适索引时，查询会退化为集合扫描。生产环境必须持续关注慢查询和执行计划。

查看执行计划：

db.orders.find({ userId: "u1", status: "paid" })
  .sort({ createdAt: -1 })
  .explain("executionStats")

关键指标包括：

• totalDocsExamined
• totalKeysExamined
• executionTimeMillis
• 是否出现 COLLSCAN

复合索引要匹配查询模式。常见原则是等值字段在前，排序字段在后，范围字段谨慎放置。例如：

db.orders.createIndex({ userId: 1, status: 1, createdAt: -1 })

索引不是越多越好。每个索引都会增加写入成本、占用内存和磁盘。长期不用的索引应清理。

复制集

复制集提供高可用。一个典型生产复制集至少包含 3 个投票节点，避免单点故障。Primary 负责写入，Secondary 复制 oplog。

需要监控：

• 复制延迟。
• oplog 窗口。
• Primary 切换次数。
• 节点磁盘延迟。
• 连接数和锁等待。

复制延迟过大时，Secondary 读可能读到旧数据。对强一致读写路径，应从 Primary 读取或使用合适的 readConcern/writeConcern。

writeConcern 与 readConcern

MongoDB 提供可调一致性。writeConcern: majority 可以要求写入被多数节点确认，提高故障安全性，但延迟会增加。生产中对核心数据建议使用 majority，非关键日志或统计可以放宽。

读取也要根据业务需求设置。读取 Secondary 可以分摊压力，但必须接受延迟。不要让支付状态、权限状态这类强一致数据从落后节点读取。

分片策略

分片能扩展容量和吞吐，但分片键选择错误会带来长期痛苦。一个好的 shard key 应具备：

• 高基数。
• 查询常用。
• 写入分布均匀。
• 避免单调递增热点。

使用 createdAt 作为分片键容易让新写入集中到一个 shard。使用低基数字段如 status 也会严重倾斜。可以考虑组合键或 hashed shard key，但要评估范围查询能力。

分片后，跨 shard 查询和聚合成本更高。分片不是性能魔法，它只是把负载分散到多个节点，同时也增加了系统复杂度。

慢查询治理

开启 profiler 或慢查询日志，建立慢查询治理流程。每条慢查询应回答：

• 查询来自哪个服务和接口。
• 是否命中索引。
• 返回文档数和扫描文档数比例。
• 是否排序使用内存。
• 是否能通过模型调整减少查询。

不要只靠加索引解决所有问题。有些慢查询本质是访问模式不适合当前模型，需要引入读模型、预聚合或搜索引擎。

备份恢复

MongoDB 备份必须定期恢复演练。复制集不是备份，分片集群也不是备份。误删、逻辑错误、批量更新错误会被复制到所有节点。

建议：

• 定期全量备份。
• 保留 oplog 用于时间点恢复。
• 备份文件异地保存。
• 每月做恢复演练。
• 记录 RTO 和 RPO。

总结

MongoDB 生产化的核心是约束灵活性。文档结构要有边界，索引要服务访问模式，复制集要监控延迟，分片键要谨慎选择，备份要能恢复。MongoDB 可以非常稳定，但前提是团队把它当成数据库系统认真治理，而不是当成无限容量的 JSON 仓库。