隐藏索引：MongoDB 5.0中那个“看不见但还在干活”的特性
简单来说，隐藏索引是MongoDB 5.0引入的一个“障眼法”。它让索引对查询优化器不可见，但索引本身依然被默默维护着，该占的磁盘空间和内存一点不少，写入开销也照旧。它并非真正禁用索引，而是临时把它从查询优化器的候选名单里拿掉——相当于给优化器戴了个眼罩，而不是把索引本身关掉。
什么是隐藏索引（hidden index）及其真实作用
理解隐藏索引，关键在于区分“对谁不可见”。它的作用对象是查询优化器，而不是数据库系统本身。
- 索引隐藏后，你在
explain(“executionStats”)的结果里就看不到它被选中了，哪怕这个索引原本是最优解。 - 通过
db.collection.getIndexes()命令查看，索引依然在列表里，只是多了一个“hidden”: true的标记。 - 这个操作在副本集里是主从同步的。你在主节点上执行，变更会通过oplog同步到所有从节点，不需要逐台机器去操作。
- 不过，它也有局限性：TTL索引、2dsphere地理空间索引，以及分片集群中的片键索引，都不支持设置为隐藏状态。
如何为副本集中的索引设置 hidden 属性
设置隐藏属性，必须使用collMod命令来修改现有索引。注意，创建索引时（createIndex）不能直接指定hidden选项。操作需要在主节点执行。
db.runCommand({
collMod: “users”,
index: {
keyPattern: { email: 1 },
hidden: true
}
})
keyPattern必须和你要隐藏的现有索引完全一致，包括字段、顺序和方向。哪怕顺序不对，也会报IndexNotFound错误。- 如果原索引带有其他选项，比如
sparse: true或者partialFilterExpression，那么在index对象里也必须把这些选项原样写上。 - 命令执行后立即生效，不需要重启MongoDB服务。
- 不同驱动支持度有差异。像PyMongo 4.7+已经支持
database.command()来调用，而Node.js驱动可能还需要借助db.adminCommand()或者对原生命令进行封装。
隐藏索引后查询性能为何可能没变化
这是最容易产生困惑的地方。很多人以为隐藏了索引，查询就一定会变慢或走全表扫描，但实际情况往往更复杂。隐藏只影响优化器的选择，以下场景可能会让你觉得“隐藏了好像没用”：
- 你的查询条件恰好只命中了一个未被隐藏的索引，优化器别无选择，自然就走它了。这时候，隐藏其他索引当然看不出区别。
- 查询语句中使用了
hint()强制指定索引。这个指令的优先级很高，会直接绕过优化器的选择，即使你隐藏了索引，它依然能被hint强制使用。 - 在聚合管道中，尤其是涉及
$lookup或$graphLookup的跨集合查询阶段，某些情况下可能会忽略索引的隐藏状态。 countDocuments()和estimatedDocumentCount()这类计数操作，本身就不经过常规的查询计划器，所以不受隐藏属性影响。- 在副本集环境中，如果你的查询读的是从节点（
SECONDARY），并且存在复制延迟，那么你查询到的可能根本不是刚刚修改后的元数据状态。
隐藏索引 vs 删除索引：什么情况下该选 hidden
那么，到底该隐藏还是该删除？这取决于你的目的。隐藏适合那些需要“留一手”的临时场景，而删除则是更彻底的清理。
- 想验证索引价值又怕手滑：你怀疑某个复合索引根本没被用到，但又不敢直接删。这时可以用隐藏，然后观察慢查询日志里
executionStats.nReturned（返回文档数）和totalDocsExamined（扫描文档数）这两个关键指标是否飙升。 - 新旧索引灰度切换：准备上线一个新索引，想先让旧索引“退居二线”，避免优化器在两个索引间摇摆不定。隐藏旧索引比删除再重建更安全，毕竟重建大索引的锁表代价可不小（即使在WiredTiger引擎下，创建索引仍会阻塞写入）。
- 拦截遗留代码中的硬编码索引：有些老代码里用
hint()写死了索引名称，一时半会儿改不了应用，但又希望这个索引暂时失效。隐藏索引是目前唯一能不修改代码就实现拦截的方法。 - 值得注意的是，隐藏索引不影响数据备份与恢复。用
mongodump备份的数据依然包含该索引的定义，mongorestore恢复后，它的隐藏状态也会保持不变。
说到底，隐藏索引不是一个简单的开关，而是一次针对查询优化器的精准干预。最容易被忽略的核心点是：它只改变优化器的视线，不改变索引的物理存在。所以，别指望隐藏索引能释放内存或降低写入放大——如果你隐藏后磁盘和内存占用没变，那不是Bug，设计就是如此。它只是让优化器“假装看不见”，而该干的活，索引一样都没少干。
