MongoDB 4.4 支持隐藏索引，需 FCV ≥ 4.4，通过 createIndex({a:1},{hidden:true}) 创建或 collMod 命令隐藏现有索引；隐藏后索引仍维护约束、TTL 和写入更新，但查询规划器完全忽略，explain 中不出现 IXSCAN，且不可 hint。
MongoDB 4.4 确实支持隐藏索引，但必须确认 FCV ≥ 4.4 且不能用 invisible 或 MySQL 风格语法——否则命令直接报错。
如何创建或隐藏索引用于聚合性能验证
隐藏索引不是“开关式灰度”，而是让查询规划器彻底忽略它，但索引本身仍参与写入、约束校验和 TTL 过期。这对聚合测试很关键：你能在不删索引的前提下，观察去掉某个索引后 $match 阶段是否变慢、是否触发全表扫描。
- 新建隐藏索引用
db.collection.createIndex({a: 1, b: -1}, {hidden: true})，必须确保featureCompatibilityVersion≥ 4.4（运行db.adminCommand({getCmdLineOpts: 1})查看） - 隐藏已有索引只能用
collMod，例如：db.runCommand({collMod: "orders", index: {keyPattern: {user_id: 1, order_date: 1}, hidden: true}})——注意keyPattern必须和getIndexes()中完全一致，字段顺序、方向一个都不能错 - 别试图用
db.collection.hideIndex("name")：这是非官方封装，4.4 原生命令不支持该语法，会报unrecognized field 'hideIndex' - 隐藏后，
db.orders.getIndexes()仍显示该索引，但多出"hidden": true字段；而explain("executionStats")的executionStages里不会出现对应IXSCAN
为什么聚合查询中隐藏索引容易误判效果
聚合管道的索引生效位置极敏感，隐藏一个索引未必等于“关掉性能瓶颈”，因为优化器可能根本没选它——尤其当 $match 条件未覆盖索引前缀，或管道里有 $lookup/$unwind 打乱了数据流。
-
$match必须在管道最前面才能走索引；如果写成[{$unwind:"$items"}, {$match:{status:"shipped"}}]，哪怕有{status:1}索引也无效 - 隐藏复合索引时，要确认它真被原查询用到：执行
db.orders.aggregate([...]).explain("executionStats")，看queryPlanner.winningPlan.inputStage.stage是否为IXSCAN，再比对keyPattern - 如果聚合返回结果少但
totalDocsExamined很高，说明索引没覆盖查询——这时隐藏它影响不大；真正要盯的是executionTimeMillis和nReturned的比值突增 - 唯一索引或 TTL 索引即使隐藏，仍强制生效：比如隐藏了
{email: 1, unique: true}，插入重复 email 仍会报E11000 duplicate key
验证时别跳过的三个实际限制
很多团队测完觉得“隐藏后没变化”，其实是没踩对验证路径。隐藏索引不是性能开关，它只影响规划器决策，其他行为照旧。
- 不能对隐藏索引用
cursor.hint()：执行db.orders.find({user_id:...}).hint("idx_hidden")会直接失败，报错hinted index is hidden -
_id索引无法隐藏：任何尝试如db.runCommand({collMod:"c", index:{keyPattern:{_id:1}, hidden:true}})都会返回cannot hide _id index - 隐藏操作不阻塞读写，但会重置
$indexStats：如果你正依赖该指标判断索引热度，重置后需重新采集至少 5 分钟以上数据才可信
最常被忽略的一点：隐藏索引后，db.currentOp() 里依然能看到它被更新的写入记录，磁盘占用和内存压力一点没少——它只是“假装不存在”于查询计划，不是资源隔离。验证聚合性能，重点不是藏得多干净，而是看 executionStats 里 totalKeysExamined 和 totalDocsExamined 的差值有没有扩大。这个差值才是回表代价的真实刻度。
