mongodb 5.0中$indexstats可精准识别冗余索引：需启用enableindexstats（重启生效），通过aggregate获取访问统计，结合零访问、前缀重叠、唯一性冲突三指标判断，删除前须验证执行计划。
在MongoDB 5.0中，$indexStats聚合阶段能真实反映每个索引的访问频次，直接查出长期未被查询引擎触达的索引，避免凭经验误删仍在生效的关键索引。
启用indexStats数据采集
确保目标集合所在数据库已开启索引统计功能：MongoDB 5.0默认启用，但若曾手动关闭过，需重启mongod时添加--setParameter enableIndexStats=true参数；该设置【不可热更新，必须重启进程】。
验证是否生效：连接到mongosh后执行db.runCommand({getParameter:1,enableIndexStats:true})，返回值中"was"字段为true即表示已激活。
获取当前集合所有索引的访问统计
切换到对应数据库，执行以下聚合命令：
db.collectionName.aggregate([{$indexStats:{}},{$sort:{accesses.ops:-1}}])
其中collectionName替换为实际集合名；$sort按访问次数降序排列，方便一眼识别零访问或极低访问的索引。
注意：accesses.ops为0仅表示自上次mongod启动以来无查询命中该索引，不等于该索引永远无用——某些定时任务或低频管理操作可能尚未触发。
识别冗余索引的三个关键指标
方法一：零访问+非_id索引
筛选accesses.ops为0且name字段不等于"_id_"的文档，这类索引大概率冗余；但需先确认该集合近期是否有写入压力突降或应用停更情况，否则可能只是暂时空闲。
方法二：前缀重叠索引
对比多个索引的key字段：若索引A的key为{"a":1,"b":1}，索引B为{"a":1,"b":1,"c":1}，且B的accesses.ops显著高于A，则A极可能被B覆盖，属于冗余；【删除前必须验证查询计划是否真由B承担】，可用db.collectionName.explain("executionStats").find({a:1,b:1})确认。
方法三：唯一性与业务逻辑冲突
检查unique字段为true但accesses.ops为0的索引：若该字段在业务中从未用于去重校验（如注册接口未启用该字段唯一约束），则该唯一索引纯属冗余；此时应同步检查应用代码和数据迁移脚本，确认无隐式依赖。
