Performance Advisor 不自动创建索引，仅基于慢查询日志提供建议；建议失效常见于字段顺序不匹配、巨型数组、$lookup/正则、缓存未预热等情况；判断价值需看Impact、Average Query Targeting（应≤1000）、Queries Benefiting，并避开冗余或功能不可用场景。
Performance Advisor 不会自动创建索引，它只提供建议；你必须手动执行 createIndex() 或点击 UI 中的 Create Index 按钮才能生效。
Performance Advisor 的建议从哪来？
它基于 Atlas 集群中实际捕获的慢查询日志生成，这些查询需同时满足两个条件：执行时间超过动态阈值（默认由集群平均操作时间决定），且 docsExamined 与 docsReturned 比值偏高。注意，如果聚合管道里有连续多个 $match，Performance Advisor 展示的“示例查询”可能已被合并简化，和你代码里写的原始结构不一致。
为什么点了 Create Index 还没提速？
常见原因包括：
- 推荐索引字段顺序和你查询的
filter、sort、projection不匹配，比如查询带{ status: 1, createdAt: -1 }但建议的是{ createdAt: 1, status: 1 } - 集合里存在大量含巨型数组的文档，即使加了索引，MongoDB 仍需展开数组做匹配，
IXSCAN后可能紧跟着高docsExamined - 查询用了
$lookup或正则表达式（如{ title: { $regex: "^The" } }），这类操作天然难走索引，Performance Advisor 的建议效果有限 - 索引刚建完，但缓存未预热，首次查询仍可能触发
COLLSCAN；可用db.collection.find().explain("executionStats")确认是否真走了新索引
如何判断这个建议值不值得建？
在 Performance Advisor 页面，优先关注三列数据：Impact（预估 QPS 提升）、Average Query Targeting（扫描/返回比，越低越好）、Queries Benefiting（受益查询数）。避开以下情况：
-
Average Query Targeting> 1000 —— 说明多数查询仍要扫大量文档，索引选择性差 - 建议索引字段包含
_id或唯一键但查询没用到等值条件，大概率无效 - 同一集合已有复合索引覆盖了建议字段的前缀，比如已有
{ a: 1, b: 1, c: 1 }，再建{ a: 1, b: 1 }属于冗余
真正容易被忽略的是：Performance Advisor 对使用 ctime 时间戳格式的数据库完全不提供建议，且免费集群（M0）默认禁用其核心分析能力——这两类场景下，你看到的“无建议”不是优化完成，而是功能不可用。
