$indexstats可查索引累计访问次数（accesses.ops）和最后访问时间（accesses.since），但数据非实时、重启清零；需结合索引选项、慢日志及代码验证，不可单凭ops=0直接删除。
如何通过 $indexStats 查看索引实际使用频率
MongoDB 从 3.2 开始提供 $indexStats 聚合阶段，它能返回每个索引自创建以来的累计访问次数（accesses.ops）和最后访问时间（accesses.since）。这不是实时监控数据，而是基于内存中统计的近似值，重启 mongod 后会清零——这点必须提前确认，否则你会误判“冷索引”。
执行方式很简单：
db.collection_name.aggregate([ { $indexStats: {} }, { $sort: { "accesses.ops": 1 } } ])
注意：collection_name 必须替换成真实集合名；该命令只对当前数据库中的指定集合有效，不跨库、不递归扫描所有集合。
-
accesses.ops === 0表示该索引从未被查询计划选中过（但不等于“完全没用”，比如它可能支撑唯一约束或被写操作隐式使用） -
accesses.since是 UTC 时间戳，若值为很久以前（如早于 6 个月），且ops极低，才具备删除候选资格 - 复合索引的字段顺序会影响匹配效果，
$indexStats不会告诉你“哪个查询本可以走它但没走”，只能反映实际命中情况
为什么不能只看 accesses.ops === 0 就删索引
零访问量看起来很诱人，但直接删除可能引发严重问题。MongoDB 的索引不止服务于 find 或 aggregate，还参与：
- 唯一约束校验（
unique: true索引被删 → 插入/更新可能违反约束而不报错？不，会直接失败） - 文档删除/更新时的查询定位（即使你不用它查，写操作仍可能依赖它快速定位目标文档）
- Change Stream 或 Oplog 捕获逻辑（某些驱动或 CDC 工具依赖特定索引加速变更拉取）
- TTL 索引（
expireAfterSeconds）即使ops为 0，也持续后台清理
更隐蔽的是：某些聚合管道中的 $lookup 或 $graphLookup 可能隐式触发索引，但因优化器选择其他路径而未计入 $indexStats。所以务必结合 db.collection_name.getIndexes() 手动检查索引选项，过滤掉带 "unique":true、"expireAfterSeconds"、"partialFilterExpression"（尤其当业务逻辑依赖该条件）的条目。
如何安全批量识别可删索引（含系统集合过滤）
生产环境不能靠肉眼翻页判断，需要用脚本遍历 + 条件过滤。以下 shell 片段可导出疑似冷索引列表（需在 mongo shell 中运行）：
db.getCollectionNames().forEach(coll => {
if (coll.startsWith("system.")) return; // 跳过系统集合
db[coll].aggregate([
{ $indexStats: {} },
{ $addFields: {
"daysSinceAccess": { $divide: [ { $subtract: [ new Date(), "$accesses.since" ] }, 1000 * 60 * 60 * 24 ] }
}
},
{ $match: {
"accesses.ops": { $lt: 10 }, // 近期几乎没用
"daysSinceAccess": { $gt: 180 }, // 最后访问超半年
"name": { $ne: "_id_" } // 保留 _id 索引
}
}
]).forEach(idx => {
print(`${coll}: ${idx.name} (ops=${idx.accesses.ops}, since=${idx.accesses.since.toISOString()})`);
});
});
关键点：
- 跳过
system.*集合，避免误操作（如system.views或system.profile） - 不筛
_id_，这是强制存在的主键索引，删了整个集合就不可写了 - 阈值设为
ops 而非 <code>=== 0，因为偶发调试查询可能干扰判断 - 结果只是候选列表，不是执行清单——必须人工核对索引用途后再操作
删除前必须验证的三个动作
发现一个“可疑索引”后，删之前至少做三件事：
- 查慢日志：
db.setProfilingLevel(1, { slowms: 100 })开启 100ms 慢查询捕获，跑 24 小时业务高峰流量，再用db.system.profile.find({ "keysExamined": { $gt: 10000 } }).sort({ ts: -1 })看是否突然出现大量全表扫描 —— 若有，可能正缺你打算删的那个索引 - 查应用代码：grep 所有
sort()、find({ ... })和聚合管道，确认没有显式 hint 或隐式依赖该索引字段组合 - 在从节点上先删（如果用副本集）：观察
rs.printSecondaryReplicationInfo()延迟是否突增，以及应用日志是否有“query not covered by index”类警告
真正危险的不是删错一个索引，而是删完后没人知道它曾被用过——监控缺失、日志轮转、交接文档空白，会让下一次排查变成盲人摸象。
