隐藏索引是验证删除影响唯一安全低风险手段，需用collMod命令严格匹配索引定义，在主节点执行并逐个同步副本集节点，仅explain("executionStats")可真实验证生效。
隐藏索引不是“预删预演”的可选操作，而是验证删除影响唯一安全、低风险的手段——它让查询规划器彻底忽略索引，又不破坏写入约束、不触发磁盘重建、不引发副本集不一致。
db.collection.hideIndex() 为什么总报错
因为 db.collection.hideIndex() 只是封装，实际必须走 collMod 命令，且参数必须严丝合缝：
-
keyPattern字段名、方向（1/-1）、顺序、空格都得和db.collection.getIndexes()返回的一模一样 - 如果原索引带
sparse: true或partialFilterExpression，这些也得一并写进命令里，漏一个就报IndexNotFound - 不能直接传字符串名，
db.collection.hideIndex("email_1")必然失败 - 必须在主节点执行；副本集的从节点不会自动同步该操作
怎么确认隐藏真的生效了
别信 getIndexes() 里看到 "hidden": true 就完事——那只是元数据标记。唯一可信验证方式是跑 explain("executionStats")：
- 查任意一条本该命中该索引的查询，比如
db.users.find({email: "a@b.com"}).explain("executionStats") - 紧盯
executionStages节点下的indexName字段：被隐藏的索引绝不会出现其中 - 如果还出现了，说明隐藏失败，或查询被
.hint()强制绕过（常见于 ORM 自动生成 hint） -
countDocuments()和estimatedDocumentCount()不走查询规划器，完全不能用来验证
隐藏后性能没变化？大概率你没测对
很多团队隐藏索引后看 QPS、延迟几乎不变，就以为“这索引没用”，其实是以下情况掩盖了真实影响：
- 当前测试语句只匹配一个未隐藏索引，优化器根本没得选
- 应用代码里写了死
.hint("my_idx")，直接跳过 hidden 判断 - 测试流量太单一，没覆盖真实业务中多字段排序 + 范围查询 + 投影组合的复杂路径
- 隐藏的是复合索引前缀（如隐藏了
{a: 1}，但保留了{a: 1, b: 1}），优化器照常用后者 - 聚合管道中
$lookup或跨库操作阶段可能忽略 hidden 状态，需单独构造 pipeline 测试
副本集环境下最容易被忽略的坑
隐藏操作不会写入 oplog，也不会自动同步到其他节点：
- 你在主节点隐藏了索引，从节点仍会按原计划使用它，导致主从查询行为不一致
- 延迟节点或隐藏节点上线后重放 oplog，无法回放隐藏操作，会“回退”出已隐藏状态
- 必须手动连上每个存活节点（包括 arbiter 以外的所有 SECONDARY），逐个执行相同
collMod命令 - 验证时要加
readPreference: "primary"，否则可能读到从节点缓存的旧执行计划
真正关键的不是“能不能隐藏”，而是能否在影子库或生产流量镜像中持续观察 24 小时以上——索引影响往往藏在长尾查询、凌晨批量任务、或突发的聚合压力里，单次 explain 很难暴露。
