在做索引治理时，直接删除一个不确定是否有用的索引风险很大，一旦删错就得在业务高峰期重建，大集合上可能要几个小时。MongoDB 4.4为此提供了隐藏索引能力，通过hidden: true让查询优化器暂时看不到这个索引，索引本身仍然正常维护。这个功能用起来很顺手，但也正因为"顺手"，不少人把它当成了低风险操作的代名词，结果出现了排序超时、执行计划抖动甚至和故障码2360相关的异常。这篇文章就把隐藏索引的机制讲清楚，再看看误用时会踩到哪些坑。
先搞清楚：隐藏索引到底改变了什么
隐藏索引的核心机制只影响一件事：查询优化器的候选集。当你执行db.collection.hideIndex("idx_name")后，索引并没有被禁用，写入路径上的维护照常进行，索引数据一个字节都不会少。变化仅仅在于生成执行计划时，规划器会把hidden标记的索引从候选列表里剔除。
这一点需要和删除索引严格区分。删除后索引不再消耗写放大，而隐藏索引依然会在每次insert、update、delete时被同步维护。如果你的目的是减少写压力，隐藏索引帮不上忙，它只是"临时下线查询能力"的开关。反过来，如果你的目的是验证某个索引是否可以被安全删除，隐藏索引就是为这个场景设计的。
还需要注意几个容易被忽略的细节：第一，_id索引不能被隐藏；第二，唯一索引被隐藏后，唯一性约束仍然生效，这一点很多文档里只是顺带一提，实际却是误用事故的高发区，下文会详细展开；第三，隐藏状态不会复制到通过文件快照等方式新建的节点上（正常副本集复制会同步），某些混合部署环境下要格外留心索引状态不一致带来的执行计划差异。
故障码2360的由来：隐藏索引与$indexStats的冲突
故障码2360对应的错误信息通常是"cannot hide index"，最典型的一类触发场景是对不存在的索引执行隐藏操作，或者对_id索引、已经处于目标状态的索引做重复操作。在旧版本中，这类操作的报错处理不够清晰，社区里常把隐藏索引相关的各类异常统称为"2360问题"，实际排查时要看具体的错误消息内容。
另一种和2360纠缠的情况出现在聚合管道里。有些监控系统会用$indexStats阶段采集索引访问统计，如果脚本在采集的同时对索引做hide或unhide操作，统计视图和索引真实状态可能短暂不一致，导致脚本误判后对同一个索引反复操作，最终触发异常。遇到这类问题时，先把自动化脚本停掉，用db.collection.getIndexes()核对每个索引的真实状态，这是最可靠的第一步。
下面是一个正确的隐藏与恢复操作示例，注意其中状态检查的部分，生产环境中永远不要省略：
// 查看当前索引及状态
db.orders.getIndexes()
// 隐藏指定索引（按名称）
db.orders.hideIndex("idx_user_created")
// 确认隐藏是否生效，观察 extra 属性中的 hidden: true
db.orders.getIndexes().forEach(function(i) {
if (i.name === "idx_user_created") {
printjson(i.extra)
}
})
// 恢复索引可见性
db.orders.unhideIndex("idx_user_created")隐藏索引误用的三个典型坑
第一个坑：唯一索引被隐藏，约束还在但查询规划变了
这是最危险的一种误用。假设你在email字段上建了唯一索引，某天怀疑它没被查询用到，就把它隐藏了。此时唯一性约束依然生效，写入不会出问题，但所有按email等值查询的语句都失去了这个索引，退化为全表扫描。业务高峰期一到，慢查询立刻堆积，而运维侧看监控会发现磁盘IO和扫描文档数暴涨，却很难第一时间联想到是几小时前那次hide操作。
第二个坑：排序依赖的索引被隐藏，内存排序触发限制
MongoDB的排序如果无法利用索引顺序，就要在内存中完成，受allowDiskUseByDefault以及排序内存上限约束。一个原本走索引排序的查询，在被隐藏了支撑索引后会变成内存排序，数据量一大直接报错或性能雪崩。排查方法是用explain观察排序阶段是否出现了SORT关键字，出现即代表没有走索引排序。
第三个坑：TTL索引被隐藏后驱逐行为异常
TTL索引的过期删除依赖后台任务扫描索引，隐藏状态下的TTL索引在部分版本上行为存在差异，官方明确建议不要隐藏TTL索引。如果你的集合数据需要自动过期，请确保对应的TTL索引始终处于可见状态，改用别的方式做索引评估。
完整的排查与恢复思路
遇到疑似隐藏索引引发的问题，建议按固定顺序排查。第一步，拉取全量索引状态，重点看extra.hidden字段；第二步，对异常查询执行explain("executionStats")，对比索引被隐藏前后的winning plan；第三步，检查是否有定时任务或自动化平台在批量操作索引；第四步，确认无误后执行unhide恢复，并在业务低峰期观察慢查询日志。
// 一次性列出所有隐藏索引
db.getCollectionNames().forEach(function(coll) {
db[coll].getIndexes().forEach(function(idx) {
if (idx.extra && idx.extra.hidden) {
print(coll + " -> " + idx.name + " [hidden]")
}
})
})
// 用执行计划验证查询是否受影响
db.orders.find({userId: 1001}).sort({createdAt: -1}).explain("executionStats")从规范角度讲，隐藏索引应该只用于索引下线前的短期评估，建议评估窗口不超过一周。评估结束后要么删除索引，要么明确unhide，避免集合中长期残留隐藏索引。可以在变更管理制度中要求所有hide操作必须登记，并配套设置提醒，防止"隐藏之后就忘了"这种最常见的人为疏漏。
最后强调一点心态上的事：隐藏索引降低了试错成本，但不等于零风险。每次hide之前先问自己三个问题，这个索引是否唯一索引、是否被排序依赖、是否是TTL索引，三个问题都排除后，再操作也不迟。养成这个习惯，故障码2360以及它背后那些慢查询事故基本就能和你绝缘了。
MongoDB故障码2360隐藏索引索引优化修改时间：2026-09-03 12:29:08