在MongoDB中，索引设计和维护直接影响查询性能，但命令行操作对不熟悉 shell 的开发者并不友好。MongoDB Compass 把索引的创建、分析、删除集中到 Indexes 标签页，可以清楚看到集合上每个索引的字段组成、类型、占用空间和命中次数。更重要的是，它和执行计划面板配合使用，能快速验证一个查询是否真正走了索引。通过图形界面管理索引，团队内部沟通成本也会明显降低。
一、认识 Compass 的索引管理入口
连接 MongoDB 实例后，在左侧选择目标数据库和集合，右侧顶部会出现 Documents、Aggregations、Schema、Explain Plan、Indexes 等标签。点击 Indexes 标签，就能看到当前集合的完整索引列表。列表中每一行代表一个索引，默认展示索引名称、索引键、类型、大小、使用次数以及属性等信息。
和 db.collection.getIndexes() 命令相比，Compass 的优势在于把索引大小和命中次数直接可视化。索引大小可以帮助判断这个索引是否占用了过多内存或磁盘，而使用次数则反映它是否真正服务过查询。一个索引即使设计得再合理，如果长期使用次数为零，也需要重新评估存在价值。
除了基本信息，属性列还能显示 unique、sparse、ttl、partial 等特性。这些属性在命令行结果中只是一些布尔标志，在 Compass 中则更清晰地标识出来。对于刚接手一个老系统的开发者，先通过这个列表摸清索引现状，是后续优化的第一步。
二、创建单字段索引和复合索引
在 Indexes 页面点击右上角的 Create Index 按钮，Compass 会打开一个索引配置面板。用户可以选择手动输入索引定义，也可以通过图形界面逐行添加字段。例如要给 orders 集合的 customer_id 字段建立一个升序索引，只需在字段名处填写 customer_id，类型选择 1（asc），然后点击创建即可。
复合索引的场景更常见。比如订单查询经常按照客户编号和下单时间排序，这时可以建立以下复合索引：
{
"customer_id": 1,
"created_at": -1
}
在 Compass 中添加两个字段行，第一行填写 customer_id 并选择 1，第二行填写 created_at 并选择 -1。创建完成后，索引名称默认会是 customer_id_1_created_at_-1。这个复合索引能同时优化等值查询 { customer_id: 123 } 和带排序的查询 { customer_id: 123 }.sort({ created_at: -1 })。但要注意复合索引遵守最左前缀原则，如果查询只用到 created_at 而不用 customer_id，这个索引通常不会被选中。
对于需要保证字段值不重复的场景，可以在创建索引时勾选 unique 选项。例如 users 集合的 email 字段，适合建立唯一索引。对于日志类集合，如果文档只需要保留一段时间，可以创建 TTL 索引，Compass 会要求填写 expireAfterSeconds 参数，MongoDB 会自动删除超过该时间范围的文档。这些操作在 shell 中都需要记住不同语法，在 Compass 中则被简化成几个选项。
三、借助执行计划验证索引是否生效
索引创建之后，不能想当然认为查询一定变快，还要观察执行计划。Compass 的 Explain Plan 标签可以针对某条查询展示详细的执行计划。切换到该标签后，输入查询条件，例如 { customer_id: 123 }，Compass 会返回 MongoDB 选择的计划以及候选计划。
执行计划中最关键的是 winningPlan 里的 stage。如果看到 COLLSCAN，说明查询仍然在扫描整个集合，没有命中任何索引；如果看到 IXSCAN，说明查询已经通过索引定位数据。下面是一个走索引的执行计划片段：
{
"winningPlan": {
"stage": "IXSCAN",
"indexName": "customer_id_1_created_at_-1",
"direction": "forward"
}
}
除了 stage，还应该关注 totalDocsExamined 和 nReturned 的关系。如果查询返回 10 条文档，却扫描了 100 万条文档，说明索引选择性不够或查询条件书写不当。理想情况下，这两个值应该尽量接近。执行计划还能显示是否使用了覆盖查询，覆盖查询不需要回表读取完整文档，性能通常更好。
建议每次创建或删除索引后，都用同一条查询对比执行计划。Compass 的优点是可以在图形界面里快速切换查询条件，不用像 shell 那样反复粘贴命令。通过对比不同索引方案下的 stage、扫描文档数和执行耗时，能较直观地判断当前索引设计是否合理。
四、清理冗余索引和规避维护风险
当集合运行一段时间后，索引列表里常常会出现几个长期不用的索引。它们不仅占用内存和磁盘空间，还会在每次写入操作时带来额外开销，因为 MongoDB 需要同步更新所有相关索引。Compass 的 Indexes 列表里，Usage 列可以显示索引被命中的次数。如果某个索引在很长周期内使用次数始终为 0，就可以考虑删除。
删除索引时，先在列表中找到对应索引，确认名称和字段组成，再点击 Drop Index 按钮。操作会立即执行，所以生产环境需要谨慎。尤其是数据量很大的集合，错误删除一个关键索引可能导致查询突然从毫秒级变成秒级。更稳妥的做法是先在测试环境或从库上验证删除后的查询表现。
除了删除，有些情况下更温和的手段是隐藏索引。隐藏索引不会参与查询优化，但索引数据仍然保留，随时可以恢复。虽然 Compass 的 Indexes 面板对隐藏索引的显示支持有限，但可以通过 shell 执行 db.collection.hideIndex('index_name')，观察一段时间后再决定是否真正删除。对于大规模集合，创建或删除索引时还要避开业务高峰期，并监控复制延迟和磁盘 IO，避免影响线上写入。
MongoDB Compass索引管理复合索引修改时间：2026-09-29 22:59:47