隐藏索引功能需 featureCompatibilityVersion ≥ 6.0，MongoDB 4.4 不支持创建或隐藏索引，仅能识别并安全删除完全重复索引，字段子集索引需谨慎验证性能影响。
隐藏索引必须满足 featureCompatibilityVersion ≥ 6.0
虽然 MongoDB 4.4 引入了 hidden 索引功能，但实际启用需要将 featureCompatibilityVersion 升级到 6.0 或更高。直接在 4.4 集群上执行 createIndex({a: 1}, {hidden: true}) 会报错 CommandNotSupported: hidden option requires FCV 6.0 or greater。这不是驱动或 shell 版本问题，而是服务端强制限制。升级 FCV 前需确认所有节点已运行 6.0+ 二进制，并完成兼容性检查。
用 collMod 隐藏现有索引（4.4 不支持，6.0+ 才可用）
MongoDB 4.4 根本不支持隐藏已有索引——db.collection.hideIndex() 和 collMod 的 hidden 选项在 4.4 中不存在。试图调用会返回 no such command: collMod 或 unrecognized field 'hidden'。这意味着：如果你还在 4.4 环境，无法使用隐藏索引做“软删除”评估，只能靠其他方式过渡。
- 降级方案：先在从库或备份库上
dropIndex()，观察慢查询日志和explain("executionStats")变化 - 监控替代：用
db.currentOp({secs_running: {$gt: 2}})+$indexStats对比索引访问频次，识别长期未被命中的“僵尸索引” - 切勿在 4.4 生产库直接删高频索引——没有隐藏兜底，出问题就得重建，耗时可能达小时级
为什么 4.4 用户更该关注完全重复索引
4.4 缺乏隐藏能力，但冗余中最容易误伤、也最容易验证的，是完全重复索引（key 字段名、顺序、方向 100% 一致）。这类索引删一个不会影响查询逻辑，也不会破坏唯一约束（因为两个索引约束相同）。用以下脚本快速扫描：
db.getCollectionNames().forEach(coll => {
const idxs = db.getCollection(coll).getIndexes();
const seen = new Set();
idxs.forEach(idx => {
if (idx.name === '_id_' || idx.name.startsWith('system.')) return;
const keyStr = JSON.stringify(idx.key);
if (seen.has(keyStr)) {
print(`⚠️ 完全重复: ${coll}.${idx.name} ← 可安全删`);
} else {
seen.add(keyStr);
}
});
});
输出中出现的索引名，可直接传给 db.collection.dropIndex()。注意：这个判断只看 key，不校验 unique、partialFilterExpression 等选项——如果两个索引 key 相同但一个是 {unique: true}，就不能删，否则丢失唯一性保障。
字段子集索引在 4.4 下不能无脑删
例如存在 {userId: 1} 和 {userId: 1, createdAt: -1}，前者看似冗余，但在 4.4 中仍需谨慎。原因有三：
- 短索引 B-tree 层级更低，对单字段等值查询（如
{userId: "abc"}）可能比长索引更快，尤其当文档体很大时 - 4.4 的查询优化器不如 6.0+ 智能，有时无法自动选择最优前缀索引，反而走错执行计划
- 部分旧业务代码可能显式
hint("_id_")或依赖特定索引名，删掉后触发QueryExceededTimeLimit
验证方法：在测试环境对目标查询跑两次 explain("executionStats")，一次带原索引，一次删掉短索引后，对比 executionTimeMillis 和 nReturned。差异超过 15%，就别删。
db.adminCommand({getCmdLineOpts: 1}) 里的 parsed.featureCompatibilityVersion 才算数。 
