1. 先搞清楚查看索引到底在查什么连接上MongoDB之后很多人第一个想做的事情就是看看某个集合里有没有建索引、建了什么索引。这个操作在平时开发调试里太常见了——慢查询排查要确认索引是否命中上线前要核对索引是否抄错了字段清理冗余索引之前要先看看哪些索引没被用到。getIndexes()几乎是每个MongoDB使用者都会用到的命令但很多人只是机械地敲一下看到一堆返回结果也不清楚每个字段代表什么更不知道这条命令背后还有哪些坑。先说结论在MongoDB里查看一个集合的索引最标准、最常用的方法就是db.collection.getIndexes()。它在mongoshMongoDB官方的Shell工具里执行也能够通过各种编程语言的驱动程序调用。返回结果是一个文档数组数组里的每个元素描述一个索引。这个命令不涉及任何性能开销因为它只是读取集合的元数据metadata不会扫描集合里的数据所以在任何环境里你都可以放心执行。但这里要顺便纠正一个常见的认知误区很多人以为“查看索引”就是把索引的名字和字段列出来就够了。实际上索引信息里包含了影响查询计划的关键内容——索引是升序还是降序、是不是唯一索引、有没有设置稀疏属性、是不是部分索引、排序规则collation是什么。这些细节直接决定了MongoDB的查询优化器query planner是否会选择这个索引以及选择之后查询是否能走对路。所以这篇文章不仅仅是教大家敲一条命令而是要彻底讲清楚索引信息从哪里看、看到的信息怎么解读、不同驱动里怎么调、GUI工具里怎么看、以及查看索引时容易踩的那些坑。我尽量把实际操作中的经验都放进来这篇内容适合刚接触MongoDB的开发者也适合已经用了一阵子但没时间细看索引元数据的运维同学。2. 最核心的方法getIndexes() 的完整用法2.1 最简单的调用方式打开你的mongosh切换到目标数据库然后直接执行db.myCollection.getIndexes()这里myCollection替换成你要查看的集合名。如果集合里只有一个默认索引也就是_id索引返回结果通常长这样[ { v: 2, key: { _id: 1 }, name: _id_ } ]v表示索引版本目前MongoDB 4.0之后基本都是2key是索引键的定义_id: 1表示对_id字段建立升序索引name是索引名称。MongoDB 会为每个集合自动创建_id索引这个索引无法被删除所以再小的集合也会有这一条。如果你的集合里还有其他索引比如在userId和createdAt上建了复合索引返回结果会变成[ { v: 2, key: { _id: 1 }, name: _id_ }, { v: 2, key: { userId: 1, createdAt: -1 }, name: userId_1_createdAt_-1 } ]注意复合索引的key对象里字段的顺序是有意义的。userId在前、createdAt在后意味着这个索引的B-Tree先按userId排序相同userId的记录再按createdAt排序。这个顺序会影响索引能否覆盖某些查询后面我会详细说。2.2 mongosh 里的简化命令show indexes在mongosh里还有一种更简短的写法不需要先指定集合show indexes这个命令会列出当前数据库下所有集合的所有索引。如果你只关心当前使用哪个数据库这个命令更高效。它本质上就是遍历当前库的每个集合分别调用getIndexes()然后把结果汇总展示。不过我个人在实战中还是更习惯用getIndexes()因为show indexes的输出格式倾向于表格化关键字段被截断字段一多看起来反而不清楚getIndexes()返回的是JSON文档可以直接复制出来做对比、写脚本批量处理在脚本或程序代码里getIndexes()是驱动原生支持的方法show indexes只是Shell工具层面的语法糖。2.3 在编程语言中调用 getIndexes()如果你的服务是Node.js、Python或Java写的想在代码里动态检查索引是否存在、是否需要创建也可以调用驱动提供的对应方法。这里给两个最常用语言的示例。Node.js使用官方的mongodb驱动const collection db.collection(myCollection); const indexes await collection.indexes(); console.log(indexes);Python使用pymongoindexes db.myCollection.index_information() for name, info in indexes.items(): print(name, info)注意一个微妙的区别pymongo的index_information()返回的是一个字典key是索引名称value是索引信息文档而Node.js驱动的indexes()和Shell里的getIndexes()一样返回的是数组。这个差异在实际写代码的时候很容易踩坑如果你用Python遍历时按数组下标取元素会直接报错。另外Java驱动的listIndexes()返回的是ListIndexesIterable需要配合迭代器使用本质上也是读取同样的索引元数据。2.4 查看指定数据库下的所有索引有时候你想看看某个数据库下到底有没有建重复索引或者想知道所有集合的索引规模可以写一个简单的循环db.getCollectionNames().forEach(function(collName) { const indexes db.getCollection(collName).getIndexes(); print(collName : indexes.length indexes); indexes.forEach(function(idx) { print( - idx.name : JSON.stringify(idx.key)); }); });这段脚本在mongosh里可以直接执行。它会遍历当前库的所有集合打印每个集合的索引数量和索引键定义。我在做索引治理的时候经常用这个脚本几分钟就能把整个库的索引情况摸清楚。提示如果集合数量特别多或者某些集合数据量大这个遍历过程依然很快因为getIndexes()只读元数据不会扫描集合数据。3. 索引字段信息到底怎么读3.1 常见字段逐个拆解getIndexes()返回的索引信息文档里不同场景下会出现不同的字段。我把常见的字段整理成一张表方便大家对照查询结果来看。字段名含义常见取值v索引版本号当前主流是2老版本可能是1key索引键定义如{userId: 1, createdAt: -1}name索引名称默认格式为字段名_方向可指定unique是否唯一索引true或缺失缺省为 falsesparse是否稀疏索引true或缺失expireAfterSecondsTTL索引的过期秒数如3600partialFilterExpression部分索引的过滤条件如{status: {$gte: 1}}weights文本索引各字段权重如{title: 10, body: 1}default_language文本索引默认语言默认englishcollation排序规则包含locale、strength等子字段2dsphereIndexVersion地理空间索引版本2或3hidden索引是否被隐藏true或缺失很多初学者看到key里1和-1可能会疑惑。1表示升序-1表示降序。对于单字段索引来说这个方向在大多数等值查询场景下并没有区别因为B-Tree顺序扫描正着走和反着走成本类似但对于复合索引和排序查询方向就很重要了。比如查询是sort({createdAt: -1})那么{createdAt: -1}的索引就能直接匹配排序顺序避免额外的内存排序。3.2 复合索引的字段顺序比想象的更重要单独把复合索引拿出来聊是因为实际项目中90%的索引问题都出在这里。看下面的索引定义{ key: { status: 1, createdAt: -1 }, name: status_1_createdAt_-1 }这个索引的最左前缀是status所以它能服务status单独查询也能服务status createdAt的联合查询但不能高效服务createdAt单独查询。查看索引时你要习惯性地在脑子里过一遍当前业务里的查询条件是否以status开头如果业务里有大量按createdAt单独查的场景这个复合索引就是白建的你需要考虑是否额外增加一个createdAt单字段索引或者调整复合索引的字段顺序。这种判断光靠看查询日志不够建索引之前先执行几次getIndexes()看一下现有索引的键顺序再决定新增索引怎么建能避免不少重复劳动。3.3 排序规则collation和部分索引的陷阱索引信息里比较容易被忽略的字段是collation和partialFilterExpression。collation决定了字符串的比较规则。同一个字段如果索引按strength: 2的英文排序规则建立那么它无法服务指定了不同排序规则的查询。你在查看索引时如果发现某个索引带collation字段就要留意查询语句里如果没带相同的collation参数这个索引很可能不会被使用。这不是索引没建成功而是排序规则不匹配导致的。partialFilterExpression是部分索引的过滤条件。比如你建了一个部分索引db.orders.createIndex( { status: 1 }, { partialFilterExpression: { status: { $gte: 3 } } } )那么getIndexes()会返回如下信息{ v: 2, key: { status: 1 }, name: status_1, partialFilterExpression: { status: { $gte: 3 } } }看到这个字段你就要明白这个索引只包含status字段值大于等于3的文档。如果你查询条件是status: 2即使写了status字段也不会走这个索引。这是部分索引的核心语义不是BUG。注意getIndexes()返回的索引信息是静态定义不代表某个索引在当前查询中实际被使用。要确认索引是否真正被使用需要配合explain()或查看慢查询日志。4. 查看索引的其他途径Compass、驱动与系统集合4.1 MongoDB Compass 图形界面如何使用如果你不喜欢命令行MongoDB官方的图形化管理工具Compass也提供了索引查看功能。连接上数据库之后选择目标集合点击页面上方的“Indexes”标签页就能看到该集合的全部索引列表。Compass的索引页会展示索引名称、索引键、属性比如Unique、Sparse、Partial等还标注了每个索引当前占用的存储大小。这个大小信息在你评估“某个索引是否值得保留”时非常有用。索引在磁盘上会额外占用空间数据量越大越明显。如果某个索引几乎没被使用且体积庞大就可以考虑删除或隐藏索引。Compass的另一个优势是可视化创建索引。在界面里选择字段、设置排序方向、勾选唯一或稀疏属性它会自动拼好创建命令你可以复制出来在Shell里执行也可以直接通过界面操作。我一般还是习惯用命令但给团队里不太熟悉MongoDB语法的同事推荐Compass上手成本确实低很多。4.2 旧版本中的 system.indexes 集合在MongoDB 3.2之前索引信息存储在每个数据库的system.indexes集合中可以直接查询。在较新版本里这个集合依然存在但行为已经发生变化。早期版本你可能会看到这样的写法db.system.indexes.find()这个命令在MongoDB 3.2 之后的版本里已经被废弃。如果你是在较新版本的mongosh里执行会得到一个提示或空结果。现代MongoDB把索引元数据统一存储在内部系统集合中不再对外暴露直接查询的接口统一通过命令层访问。我建议不要试图去查询system.indexes原因有两点该集合的内部结构可能在未来版本中变化你的脚本会变得脆弱官方文档明确指出应使用getIndexes()获取索引信息系统集合查询行为不受兼容性保证。4.3 通过 explain 输出确认索引信息getIndexes()只告诉你“有哪些索引”不告诉你“查询用了哪个索引”。如果你遇到“查询慢”但“索引看了一圈感觉都有”的情况就需要用explain()来查看实际的查询执行计划。db.myCollection.find({ userId: 123 }).explain(executionStats)输出的winningPlan部分会显示实际使用的索引名winningPlan: { stage: FETCH, inputStage: { stage: IXSCAN, indexName: userId_1 } }IXSCAN表示走了索引扫描indexName指明用的是哪个索引。如果stage显示COLLSCAN说明这个查询是全集合扫描索引没有生效。结合getIndexes()查询结果和explain()的查询计划你就能准确定位问题。我需要特别强调一点索引配置和索引使用是两件事。很多人一看到“集合里明明建了索引查询还是慢”就开始怀疑MongoDB的优化器有问题其实大多数情况要么是查询写法没走索引前缀要么是索引排序规则不匹配要么是索引统计信息过旧。先在getIndexes()里确认索引定义格式与你预期的完全一致再配合explain()查看执行计划别凭感觉做优化。5. 查看索引时的常见问题与避坑指南5.1 问题速查表为什么命令报错或结果不对这里把我实际工作中见过的情况整理成了一张速查表遇到类似问题可以对照着看。现象可能原因解决方案getIndexes()返回not found集合名拼写错误或者当前database不对确认db指向正确执行show collections查看集合列表返回结果只有一个_id索引集合确实没有其他索引或者索引是在其他集合上建的核对集合名用show indexes看当前库全部索引索引键方向和自己建的不一致建索引时传参有误或索引名称重复导致没创建成功检查createIndex的参数顺序索引字段顺序不能错Python里index_information()返回类型是字典与Shell返回数组不同这是驱动设计差异按字典方式遍历不要按数组索引访问system.indexes查询无结果新版MongoDB不再支持直接查询该系统集合改用getIndexes()重复创建同名索引索引名冲突但键不同删除旧索引或指定不同的索引名称5.2 索引数量过多时的排查思路一个集合的索引数量并不是越多越好。每次插入、更新文档时所有索引都需要同步维护。写入压力大的集合如果索引数量过多写性能会明显下降。当你通过getIndexes()发现某个集合有七八个甚至十几个索引时需要重点排查是否存在功能重复的索引例如既有{status: 1}又有{status: 1, createdAt: -1}后者已经能服务前者的查询前者属于冗余是否存在无人使用的索引可以通过Compass查看索引操作次数或在MongoDB Atlas中查看索引使用统计是否存在TXT索引和哈希索引等特殊索引被误建的情况这类索引在普通业务查询里几乎不会被用到。排查之后对于确属冗余的索引使用db.myCollection.dropIndex(索引名称)删除。注意删除索引之后依赖该索引的查询会退化为全表扫描务必在业务低峰期操作并且先在测试环境验证。5.3 隐藏索引先试删再真删的安全手段MongoDB 4.4 开始的隐藏索引hidden index功能非常值得配合getIndexes()来用。创建隐藏索引时索引依然存在并继续被维护但查询优化器不会选它。这样你可以模拟“删除索引”的效果观察业务查询是否出现性能退化而不必真正删除索引。确认安全后再真正删除或者决定保留。创建一个隐藏索引db.myCollection.createIndex( { userId: 1 }, { hidden: true } )查看索引时返回结果里会有hidden: true字段。这里有个点需要在getIndexes()里注意一下如果你在集合上创建了同名字的已存在索引再指定hidden: true可能不会生效因为重名索引创建行为是更新属性的存在一些版本兼容性问题。稳妥的做法是给隐藏索引起一个不同的名称用name参数显式指定。5.4 经验总结查看索引之后顺手做这三件事每次执行完getIndexes()之后我都会下意识地做三个动作第一数一数索引数量。单集合索引数量一般不建议超过5个超过之后就要提高警惕逐一确认每个索引的不可替代性。第二确认_id索引之外是否有至少一个能覆盖高频查询条件的索引。这个“覆盖”不仅指字段存在还要索引键顺序能匹配查询条件的最左前缀。第三检查是否有索引名称不符合团队规范。比如索引名称最好是字段_方向的组合可读性强也方便在慢查询日志里识别。如果看到类似xyz123这种默认兼容格式的索引名建议在后续版本迭代中统一规范。这些都是很微小的习惯但坚持下来能避免很多后续沟通成本。毕竟索引是MongoDB性能的基石建错一个索引早高峰可能引发全库慢查询配置规范清晰监控指标也更容易解读。