## 01、痛点

昨晚凌晨两点，运维群又炸了：订单查询超时，MongoDB CPU 飙到 95%。我打开慢查询一看，一个简单的租户商品筛选居然扫了 40 万行。更离谱的是，这个集合上建了 18 个索引。我是老李，这几年在云上帮不少团队收拾过 MongoDB 的烂摊子。今天不聊玄学，就聊一个被很多人忽略的原则：索引不是看到字段就加，而是从真实查询模式反推。

很多开发同学的习惯是，接口一开始慢，就想着“给这个字段加个 @Indexed”。今天加一个状态，明天加一个时间，后天再加一个租户。几个月后，集合里索引比字段还多。读查询没快多少，写入延迟却从 20 毫秒涨到 400 毫秒。为什么现在要讲？因为云 MongoDB 越来越普及，业务查询越来越复杂，错误索引策略的成本被成倍放大。继续靠“见字段就加”的老思路，只会让数据库又慢又胖。

## 02、是什么

MongoDB 性能优化第一原则不是看到字段就加 @Indexed，而是从真实 Query Pattern 反推索引。什么叫真实 Query Pattern？就是你线上实际跑的那批查询：哪些字段做等值过滤，哪些字段做范围过滤，哪个字段排序，分页怎么取，返回哪些字段。索引存在的唯一目的，是让这些查询少扫描、少排序、少回表。

MongoDB 里的索引类型很多，先说清楚各自定位。单字段索引适合只有一个字段过滤的查询；Compound 复合索引适合多字段组合过滤，这是最常用也最容易建错的一类；Multikey 多键索引解决数组字段内元素查询；Text 文本索引处理全文搜索；Geo 地理空间索引处理坐标距离；Wildcard 通配符索引适合字段结构不确定的场景。除了这些类型，还有一个很重要的思路叫 Covered Query，也就是查询要返回的字段全部都在索引里，MongoDB 可以只读索引不读文档，性能最好。而复合索引字段顺序的核心思路是 ESR：Equality 等值字段放最左，Sort 排序字段放中间，Range 范围字段放最后。这个原则后面会展开。

这里必须提一句 Spring Data 的默认行为。Spring Data MongoDB 从 3.0 开始，默认不会在启动时自动创建索引。官方更推荐你显式管理索引。原因很简单：隐式建索引会让启动过程多做很多额外的事情，而且容易脱离版本管理，出问题不好排查。索引应该像代码一样，有创建脚本、有版本记录、有评审流程。

## 03、为什么

为什么索引越多，写入反而越慢？要理解这一点，得先理解 MongoDB 的写入路径。MongoDB 默认使用 WiredTiger 存储引擎，每个索引本质上都是一棵独立的 B-tree。你插入一条文档时，除了写主文档，还要同步更新这棵 B-tree。集合上有 18 个索引，插入一条就要维护 18 棵索引树。这个维护不是免费的：它会产生额外的内存页修改、写前日志量、checkpoint 压力和磁盘 IO。尤其在写入吞吐大的场景下，索引维护成本会直接拉高延迟。

那为什么不能只加索引解决查询？因为查询计划器会选择索引，但多个相似索引会互相干扰。MongoDB 的查询计划器会为候选索引生成执行计划，通过采样跑分选出 winner。如果索引很多，计划器选择也不一定最优，甚至缓存到不合适的计划。更关键的是，索引设计顺序错了，复合索引等于白建。

这里重点说 ESR 原则。ESR 代表 Equality、Sort、Range，它决定了复合索引字段的排列顺序。等值字段最左，是因为 B-tree 连续匹配等值条件最稳定；排序字段放中间，是因为只有索引键的前缀精确匹配后，排序才能直接利用索引顺序，避免内存排序；范围字段放最后，是因为范围条件会中断索引键的严格顺序，如果范围字段提前，后面的排序字段就无法被索引顺序覆盖。举个例子，查询 tenantId = 't-123' 且 price <= 5000，按 createTime 倒序取 20 条。如果把 price 放在 createTime 前面，排序就可能需要额外 SORT 阶段，扫描的量也会变大。

Covered Query 则是另一个极端。如果查询字段和返回字段都落在同一个索引里，MongoDB 根本不需要 FETCH 文档，直接从索引取数返回。这种查询的 totalDocsExamined 是 0。索引键本身也是数据，这是 MongoDB 索引设计的一个重要认知。

## 04、架构

从架构层面看，MongoDB 的索引不是元数据，而是真实的存储结构。WiredTiger 里每个索引都是一棵单独的 B-tree，叶子节点存的是索引键和指向主文档的内部记录号。复合索引的键值按字段顺序拼接成一个有序 value。比如 {tenantId:1, category:1, status:1}，索引条目会先按 tenantId 排序，再按 category，再按 status。所以最左前缀匹配是关键。

多键索引稍微复杂一点。一个数组字段会展开成多个索引条目，每个元素对应一个条目。文档更新数组时，索引维护成本会翻倍。通配符索引则是对文档内所有字段或匹配字段建立索引条目，适合 schema 不固定的集合，但也会放大写放大。文本索引和地理索引有自己专门的存储结构，分别用于倒排索引和二维球面坐标。

查询执行时，MongoDB 的查询计划器会遍历候选索引，为每个候选索引采样执行，根据 fetched 文档数和排序成本打分，选出 winning plan，并缓存一段时间。所以 explain 输出里的 winningPlan 和 rejectedPlans 是判断索引是否生效的关键。如果 winningPlan 里出现 COLLSCAN 或者 SORT stage，就要警惕了。

写入路径上，主文档更新会同步更新所有相关索引。WiredTiger 的写事务会先写内存，再写 journal，最后 checkpoint。索引更新会让这个过程的写放大更明显。这也是为什么写入密集型集合要克制索引数量，尤其是多键和通配索引。

## 05、实战

这里给一个真实的租户商品筛选场景。集合 products 上有查询：

db.products.find({
  tenantId: 't-123',
  category: 'electronics',
  status: 'active',
  price: { $lte: 5000 }
}).sort({ createTime: -1 }).limit(20)

这个查询的条件是：tenantId、category、status 三个等值，price 是范围，createTime 是排序。很多同学的直觉是分别给 tenantId、category、status、price、createTime 建五个单字段索引。结果查询可能只用其中一个索引，扫描大量文档后还要在内存排序，超时频繁。

正确做法是用 ESR 设计一个复合索引。三个等值字段放最左，排序字段 createTime 放中间，范围字段 price 放最后：

db.products.createIndex({
  tenantId: 1,
  category: 1,
  status: 1,
  createTime: -1,
  price: 1
}, { name: 'idx_tenant_cat_status_time_price' })

然后执行 explain：

db.products.find(...).sort(...).explain('executionStats')

看关键指标。winnedPlan 的 inputStage 应该是 IXSCAN，indexName 是 idx_tenant_cat_status_time_price，direction 为 backward 或 forward，取决于 createTime 的索引方向与排序方向是否一致。totalKeysExamined 接近 limit 的 20，totalDocsExamined 也接近 20。更重要的是没有 SORT stage。说明排序直接由索引顺序完成，price 条件作为索引扫描过程中的过滤条件，扫描范围被控制得很小。

如果反着建，比如把 price 放在 createTime 前面，同样条件下 explain 会显示 totalKeysExamined 可能几千甚至几万，还会出现 SORT stage，执行时间明显变长。这个对比能直接说明 ESR 的价值。

explain 输出的简化版大致是这样：

winnedPlan:
  stage: LIMIT
  inputStage:
    stage: FETCH
    inputStage:
      stage: IXSCAN
      indexName: idx_tenant_cat_status_time_price
      direction: backward

totalKeysExamined: 20
totalDocsExamined: 20
executionTimeMillis: 0

这就是一次教科书式的索引命中。注意 price 放在最后虽然不能作为等值前缀，但它作为范围条件在扫描时过滤，依然能减少回表次数。追求 Covered Query 的话，可以把需要返回的字段也加入索引，但要在索引大小和写入成本之间权衡。

## 06、洞见

Schema 与 Index 是一体的。文档结构改变以后，查询和索引也应该一起重新评估。这是我在生产环境反复看到的坑。

比如商品价格从 number 改成 { amount: 100, currency: 'CNY' }，原来的 price 索引就再也匹配不上了，查询会静默退化到 COLLSCAN。比如 category 从字符串改成数组，原来的单字段索引变成了多键索引，但查询计划可能完全改变。再比如 tenantId 字段重命名或者大小写规范化，旧索引没删，新的查询又建了新的索引，结果集合里一堆死索引，写入继续被拖累。

所以不要把索引当成一次性配置。Schema 是查询的土壤，索引是查询的路径。土壤变了，路径必须重新修。也不要过度依赖 Spring Data 那套注解自动建索引。从 3.0 开始，官方已经默认不自动创建索引，就是希望团队把索引管理显式化。索引创建脚本应该和代码变更一起评审，删除旧索引也要有流程。

另一个洞见是：索引数量不是能力，而是债务。每个索引都是写路径上的税。一个查询能用一个复合索引解决，就不要建三个单字段索引。把查询模式沉淀成索引资产，比堆积索引聪明得多。

## 07、行动

光知道理论不够，落地动作要具体。我建议给 Top10 查询建立“Query → Index → Explain”清单。这里的 Top10 查询来自慢日志、Profiler 或者业务核心接口抓取。

具体步骤如下：

第一，抓取 Top10 查询，记录完整的查询条件、排序字段、分页大小、返回字段。第二，为每条查询设计候选索引，按照 ESR 顺序先排等值、再排排序、最后排范围。第三，在测试环境执行 explain('executionStats')，确认 winningPlan 是 IXSCAN，没有 COLLSCAN 和 SORT stage。第四，记录 totalKeysExamined、totalDocsExamined、executionTimeMillis，作为基线和上线后对比。第五，把索引创建脚本纳入版本管理，显式执行，而不是依赖启动自动建索引。第六，评估索引对写入的影响，在写入基准上跑一轮，观察延迟和磁盘 IO。第七，每季度或每次大版本 Schema 变更后，重新评审 Top10 查询和索引清单。

清单模板可以是这样的：

| 查询 | 等值字段 | 排序字段 | 范围字段 | 候选索引 | explain 结果 | 写影响 |
|---|---|---|---|---|---|---|
| 租户商品筛选 | tenantId, category, status | createTime | price | idx_tenant_cat_status_time_price | totalKeysExamined=20, 无 SORT | 可接受 |

这张表放到团队文档里，比任何口头约定都有用。索引评审会成为查询优化的一部分，而不是事后救火。

## 08、小结

MongoDB 性能优化第一原则：从真实 Query Pattern 反推索引，而不是看到字段就加 @Indexed。单字段、复合、多键、文本、地理、通配和 Covered Query 是不同工具，但复合索引的 ESR 顺序决定成败。每个索引都会增加写成本，所以索引越多写入越慢。演练中，我们用 tenantId + category + status + createTime + price 的联合索引解决了一个典型租户筛选查询。Schema 与 Index 是一体的，文档结构变了，查询和索引也要一起重新评估。最终落地的动作就是给 Top10 查询建立“Query → Index → Explain”清单，并且记住：Spring Data 3.0 起默认不自动创建索引，显式管理才是正道。

## 09、链接与概念说明

单字段索引：仅包含一个字段的索引，适合简单等值过滤。
Compound 复合索引：包含多个字段的索引，字段顺序影响查询效率，遵循最左前缀匹配。
Multikey 多键索引：针对数组字段的索引，会为数组每个元素创建一个索引条目。
Text 文本索引：用于全文搜索，基于倒排索引实现。
Geo 地理空间索引：用于地理坐标查询，支持 2dsphere 等类型。
Wildcard 通配符索引：对文档中匹配通配符模式的字段建索引，适合 Schema 不固定的场景。
Covered Query 覆盖查询：查询返回字段全部来自索引，无需 FETCH 文档。
ESR：等值、排序、范围的字段排列原则，用于设计复合索引。
Spring Data MongoDB 3.0：从该版本起默认不自动创建索引，官方推荐显式管理索引生命周期。
MongoDB 官方文档：https://www.mongodb.com/docs/manual/indexes/ 
Spring Data MongoDB 参考：https://docs.spring.io/spring-data/mongodb/reference/

这些概念不用背，但每次设计索引时拿出来对照，能少走很多弯路。

昨晚凌晨两点，运维群又炸了：订单查询超时，MongoDB CPU 飙到 95%。我打开慢查询一看，一个简单的租户商品筛选居然扫了 40 万行。更离谱的是，这个集合上建了 18 个索引。我是老李，这几年在云上帮不少团队收拾过 MongoDB 的烂摊子。今天不聊玄学，就聊一个被很多人忽略的原则：索引不是看到字段就加，而是从真实查询模式反推。

《Spring Mongo实战》第11招 索引跟着查询走

从真实 Query Pattern 反推索引，详解 ESR 复合索引设计与 explain 验证，厘清索引越多写入越慢的底层原因。

架构师

数据库

后端

开发工具

MongoDB性能优化核心：从真实查询模式反推索引设计，而非随意加索引。复合索引遵循ESR原则（等值、排序、范围），可大幅提升查询效率。18个索引导致写入延迟从20ms飙至400ms，合理设计索引后扫描量降至20条。通过Query→Index→Explain清单管理索引生命周期，避免Schema变更引发的性能退化。

MongoDB

ES特惠专场，新客首购5.5折起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Mongo实战》第11招 索引跟着查询走-腾讯云开发者社区-腾讯云

《Spring Mongo实战》第11招索引跟着查询走

《Spring Mongo实战》第11招索引跟着查询走

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Mongo实战》第11招 索引跟着查询走

《Spring Mongo实战》第11招 索引跟着查询走

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Mongo实战》第11招索引跟着查询走

《Spring Mongo实战》第11招索引跟着查询走