mongodb中count()性能优化需创建满足最左前缀和覆盖条件的复合索引，优先按等值字段+范围字段顺序建升序索引（如{status:1,createdat:1}），并通过explain验证totalkeysexamined远小于totaldocsexamined及stage为ixscan。
在MongoDB中对海量集合执行count()操作时，若未命中索引或仅命中低效单字段索引，响应可能从毫秒级飙升至数秒甚至超时。复合索引能将count()从全集合扫描降为索引遍历，前提是满足最左前缀与覆盖条件。
确认count()是否真的走索引
先运行带explain的count查询，观察executionStats中的“nReturned”和“totalKeysExamined”是否接近：
db.orders.explain("executionStats").count({ status: "shipped", createdAt: { $gte: ISODate("2025-01-01") } })
如果totalKeysExamined远小于totalDocsExamined，说明已走索引；若二者几乎相等，说明仍在扫文档——此时必须建复合索引。
创建能加速count的复合索引
方法一：按查询条件字段顺序建升序索引（推荐）
db.orders.createIndex({ status: 1, createdAt: 1 })
这一步必须确保status是高频等值过滤字段，createdAt是范围条件字段。MongoDB会用该索引直接统计符合条件的索引键数量，无需读取原始文档。
方法二：添加_id字段收尾，强制覆盖（仅当需要极致性能且_id不参与查询条件时）
db.orders.createIndex({ status: 1, createdAt: 1, _id: 1 })
【注意】此索引体积更大，仅在status+createdAt组合选择性极高、且count()调用量极大时启用；日常场景优先用方法一。
验证索引是否生效于count操作
第一步：删除已有无关索引，避免干扰判断
db.orders.dropIndex("status_1")
第二步：执行带hint的count，强制使用新索引
db.orders.count({ status: "shipped", createdAt: { $gte: ISODate("2025-01-01") } }).hint({ status: 1, createdAt: 1 })
第三步：对比hint前后执行时间，若差异显著（如从1200ms降至8ms），说明索引已起效。
第四步：检查执行计划中"stage"是否为IXSCAN而非COLLSCAN——这是唯一硬指标。
