隐藏索引是MongoDB 5.0引入的特性，使索引对查询优化器不可见但持续维护；它不释放磁盘/内存，仅屏蔽其在执行计划中的选择，适用于灰度验证、避免误用或临时拦截hint等场景。
什么是隐藏索引（hidden index）及其真实作用
隐藏索引是 MongoDB 5.0 引入的特性，它让索引对查询优化器“不可见”，但依然被维护、占用磁盘空间、参与写入开销。它不是禁用索引，而是临时移除其对 query planner 的影响——相当于给优化器加了个“眼罩”，不等于停掉索引本身。
- 隐藏后，
explain("executionStats")中不会选中该索引，即使它本可命中 -
db.collection.getIndexes()仍显示"hidden": true字段 - 副本集所有节点会同步该隐藏状态（依赖 oplog 写入），无需逐台操作
- 不支持在 TTL 索引、2dsphere 索引或分片集群的片键索引上设置 hidden
如何为副本集中的索引设置 hidden 属性
必须通过 collMod 命令修改现有索引，不能建索引时直接指定（createIndex 不接受 hidden 选项）。操作需在主节点执行，自动同步到从节点。
db.runCommand({
collMod: "users",
index: {
keyPattern: { email: 1 },
hidden: true
}
})
-
keyPattern必须与现有索引完全一致（包括字段顺序、方向、前缀等），否则报错IndexNotFound - 若索引带选项（如
sparse: true或partialFilterExpression），这些也必须一并写进index对象里 - 执行后立即生效，无需重启 mongod 或重新加载配置
- 某些驱动（如 PyMongo 4.7+）已支持
database.command()调用，但 Node.js driver 需用db.adminCommand()或原生命令封装
隐藏索引后查询性能为何可能没变化
常见误解是“隐藏 = 索引不工作”，但实际影响只发生在查询计划阶段。以下情况会让隐藏失效或掩盖真实效果：
- 查询语句恰好只匹配一个未隐藏索引，优化器别无选择，自然走它——此时隐藏其他索引看不出差别
- 使用了
hint()强制指定索引，hint会绕过 hidden 判断，仍可命中被隐藏的索引 - 聚合管道中含
$lookup或$graphLookup，部分阶段可能忽略 hidden 状态（尤其跨库场景） -
countDocuments()或estimatedDocumentCount()不走 query planner，不受 hidden 影响 - 副本集从节点若处于
SECONDARY状态且未启用readPreference: "primary"，你查的可能根本不是刚改完的状态（延迟导致）
隐藏索引 vs 删除索引：什么情况下该选 hidden
隐藏适合短期验证、灰度观察、或保留索引结构但暂停干扰查询路径的场景；删除则彻底释放资源但重建成本高。
- 你想确认某复合索引是否真被误用，又不敢删——用 hidden 观察慢查询日志中
executionStats.nReturned和totalDocsExamined是否上升 - 正在上线新索引，想先隐藏旧索引避免优化器“摇摆”——比删了再重建更安全，也避免重建期间锁表（WiredTiger 下创建索引仍会阻塞写入）
- 某个索引被
hint()硬编码在老代码里，暂时不能改应用，但想让它失效——hidden 是唯一不改代码的拦截方式 - 注意：
hidden不影响mongodump或mongorestore，备份里仍含该索引定义；恢复后状态保持不变
隐藏索引不是开关，而是一次精准的 planner 干预。真正容易被忽略的是：它不改变索引的物理存在，也不减少内存压力或写放大——只是让优化器“假装看不见”。如果你看到隐藏后内存或磁盘没降，那不是 bug，是设计如此。
