hidden验证索引删除影响的正确方式是用collmod命令隐藏索引，使其被查询规划器彻底无视；必须在主节点执行且keypattern等参数须完全一致，唯一可信验证是explain("executionstats")中executionstages不出现该索引。
怎么用 hidden 真实验证索引删除影响
隐藏索引不是“关掉索引”，而是让查询规划器彻底无视它——这才是验证删除后果最安全、最低风险的方式。你不需要停写、不用切流量、更不用重建索引，只要在主节点上执行一次 collMod，就能模拟“该索引不存在”的真实查询行为。
关键操作必须用原生命令，db.collection.hideIndex() 在 mongosh 中只是封装，实际调用仍走 collMod；直接调用会报错：TypeError: db.collection.hideIndex is not a function（尤其在较新版本或 Atlas 部署中）。
- 必须在主节点上运行：
db.runCommand({collMod: "users", index: {keyPattern: {email: 1}, hidden: true}}) -
keyPattern必须和现有索引字段名、方向、顺序完全一致，多一个空格、换行或大小写差异都会触发IndexNotFound - 如果原索引带
sparse: true或partialFilterExpression，这些也得一并写进index对象里，否则命令失败 - 副本集下无需手动同步，oplog 自动广播；但 secondary 节点需显式设置
readPreference: "primary"才能立刻看到效果
为什么 explain("executionStats") 是唯一可信验证方式
别信 db.collection.getIndexes() 返回了 "hidden": true 就以为生效了——那只是元数据标记，不反映实际查询行为。真正起作用的，只看 explain("executionStats") 输出里的 executionStages 字段：被隐藏的索引绝不会出现在任何 indexName 中，哪怕它本可完美命中查询条件。
-
countDocuments()和estimatedDocumentCount()不走 query planner，完全不受hidden影响，不能用来验证 - 用了
.hint("my_idx")？隐藏完全失效：hint 会绕过 hidden 判断，强制走该索引 - 聚合管道中
$lookup或跨库操作时，部分阶段可能忽略 hidden 状态，必须单独对 pipeline 阶段做explain
隐藏后性能没变？常见误判点
很多团队测完发现 QPS、延迟几乎不变，就以为“这索引本来就不重要”，其实很可能是以下情况掩盖了真实影响：
- 当前查询只匹配一个未隐藏索引，优化器别无选择，自然看不出差别
- 应用层代码写了死
.hint()，或者 ORM 自动生成了 hint（比如 Mongoose 的.hint()调用），把 hidden 绕过去了 - 测试只跑了单条语句，没覆盖真实业务中多个排序 + 范围组合的复杂路径
- 隐藏的是复合索引的前缀部分（比如隐藏了
{a:1}，但保留了{a:1,b:1}），优化器仍可用后者，根本感知不到变化
真正关键的是：在生产流量镜像或影子库中，持续观察 24–72 小时的 executionStats.totalDocsExamined 和 executionTimeMillis 变化。
隐藏索引 ≠ 删除索引，但代价不低
隐藏索引仍然参与写入更新、消耗磁盘空间和内存，也会出现在 db.collection.stats() 和 $indexstats 中。它只是对查询规划器“不可见”，不是“不存在”。
- 如果是唯一索引，隐藏后仍会校验唯一性约束；是 TTL 索引，仍会触发文档过期
- 隐藏或取消隐藏都会重置该索引的
$indexstats，历史访问统计清零 - 无法隐藏
_id索引；且 featureCompatibilityVersion 必须 ≥ 5.0
最容易被忽略的一点：隐藏索引后不做持续观察，只比对单次 explain，等于白测。真实影响往往藏在长尾查询、高并发竞争或复合排序场景里，不在第一条 find 的输出中。
