隐藏索引是让查询规划器彻底忽略索引以安全验证删除影响的手段，需用db.runCommand({collMod:...})设置hidden:true，且keyPattern等必须完全匹配；生效与否唯一可信验证方式是explain("executionStats")中executionStages不出现该索引名。
隐藏索引不是“禁用”，而是让查询规划器彻底忽略它——这是验证删除影响最安全、最低成本的方式。
db.collection.hideIndex() 不能直接用，得走 collMod
你执行 db.collection.hideIndex("my_idx") 会报错：该方法在 mongosh 里只是 collMod 的封装，实际调用必须用原生命令。真正生效的操作是：
- 在主节点上运行
db.runCommand({collMod: "users", index: {keyPattern: {email: 1}, hidden: true}}) -
keyPattern必须和现有索引字段名、方向、顺序完全一致，哪怕多一个空格或换行都可能触发IndexNotFound - 如果原索引带
sparse: true或partialFilterExpression，这些选项也得一并写进index对象里，否则命令失败 - 副本集下无需手动同步，oplog 自动广播到所有节点（但 SECONDARY 节点需启用
readPreference: "primary"才能立刻看到效果）
explain("executionStats") 是唯一可信的验证入口
隐藏是否生效，只看 explain("executionStats") 输出里的 executionStages ——被隐藏的索引绝不会出现在 indexName 字段中，哪怕它本可完美命中查询条件。
- 别信
db.collection.getIndexes()返回了"hidden": true就以为完事了；那只是元数据标记，不反映实际查询行为 - 如果用了
.hint("my_idx")，隐藏完全失效：hint 会绕过 hidden 判断，强制走该索引 - 聚合管道中
$lookup或跨库操作时，部分阶段可能忽略 hidden 状态，需单独测试 -
countDocuments()和estimatedDocumentCount()不走 query planner，不受 hidden 影响，不能用来验证
为什么隐藏后性能没变？常见误判点
隐藏索引 ≠ 查询变慢，更不等于“起效”。很多团队测完发现 QPS、延迟几乎不变，就以为“这索引本来就不重要”，其实可能是以下情况掩盖了真实影响：
- 当前查询只匹配一个未隐藏索引，优化器别无选择，自然看不出差别
- 应用层代码里写了死 hint，或者 ORM 自动生成了
hint，把隐藏绕过去了 - 测试流量太小，或只跑了单条语句，没覆盖真实业务中多个排序+范围组合的复杂路径
- 隐藏的是复合索引的前缀部分（比如隐藏了
{a:1}，但保留了{a:1,b:1}），优化器仍可用后者，根本感知不到变化
真正关键的是：在生产流量镜像或影子库中，持续观察 24–72 小时的 executionStats.totalDocsExamined 和 executionTimeMillis 分布变化——尤其关注 P95/P99 延迟毛刺和慢日志突增。隐藏索引本身不释放资源，但它是唯一能让你“不动结构、只改 planner 行为”来闭环验证的手段。
