MongoDB 查询慢或需要索引优化时…

当用户询问 MongoDB 查询优化、索引设计、查询为何慢或集群慢查询时，通过 MCP 工具收集索引、explain、样本文档和 Atlas Performance Advisor 数据来给出优化建议。

适用场景

解决思路

1. 仅在用户明确要求优化、性能、慢查询或索引帮助时触发；常规查询编写不要触发。
2. 优先把建立索引作为优化策略。
3. 若用户想查看慢查询或寻求通用性能建议（不针对特定查询）：调用 MongoDB MCP 的 atlas-get-performance-advisor 工具获取慢查询日志和 Performance Advisor 输出，并据此给出建议。
4. 若 Atlas MCP Server 未配置或无法确定正确集群：告知用户通用性能分析需要配置带 API 凭据的 Atlas MCP Server，建议其配置或改为询问具体查询。
5. 若用户针对某个具体查询：使用 collection-indexes、explain、find 三个 MCP 工具获取集合现有索引、查询的 explain() 输出和一条样本文档。
6. 同时使用 atlas-get-performance-advisor MCP 工具获取慢查询日志和 Performance Advisor 输出。
7. 基于收集到的信息和 MongoDB 最佳实践及参考文件中的示例给出优化建议，尽量创建能完全覆盖该查询的索引。
8. 若无法使用 MongoDB MCP Server，仍应尝试给出建议。
9. 调用 MCP 时以精确工具名作为 toolName，参数作为单个 arguments 对象传入，不要把工具名当作选项、查询参数或嵌套键。
10. collection-indexes 参数：{ "database": "<db>", "collection": "<coll>" }，两者均为必填字符串。
11. explain 参数：{ "database": "<db>", "collection": "<coll>", "method": [ { "name": "find", "arguments": { "filter": {...}, "sort": {...}, "limit": N } } ], "verbosity": "executionStats" }；method 为单元素数组，name 可为 find、aggregate 或 count，arguments 放该方法参数；verbosity 可选 queryPlanner（默认）、executionStats、queryPlannerExtended、allPlansExecution。
12. find 参数：{ "database": "<db>", "collection": "<coll>", "filter": {...}, "projection": {...}, "sort": {...}, "limit": N }；database、collection、filter 必填，projection、sort、limit 可选。
13. atlas-list-projects 参数：{} 或 { "orgId": "<24-char hex>" }，返回项目及其 ID，用于获取 Performance Advisor 所需的 projectId。
14. atlas-get-performance-advisor 必填参数：projectId（24 位十六进制字符串）、clusterName（1–64 字符，字母数字/下划线/短横线）；可选 operations 数组，取值来自 suggestedIndexes、dropIndexSuggestions、slowQueryLogs、schemaSuggestions，只请求需要的；仅 slowQueryLogs 时可加 since（ISO 8601 日期时间）和 namespaces（"db.coll" 字符串数组）。
15. 当数据库连接串可用时，典型流程：调用 collection-indexes → explain → find（样本文档）。
16. collection-indexes：用结果中的 classicIndexes（每个含 name、key）判断查询是否已能用现有索引。
17. explain：先用 queryPlanner 模式检查是否 COLLSCAN；若查询使用了索引或集合很小，再用 executionStats（10 秒超时）获取扫描文档数与返回文档数。
18. 当 Atlas API 可用时，若需要 projectId 先调用 atlas-list-projects，再调用 atlas-get-performance-advisor，且只传需要的 operations。
19. slowQueryLogs：获取慢查询，按最慢和最频繁优先；可用 namespaces 限定集合、since 限定时间窗口。
20. suggestedIndexes：获取集群索引推荐。
21. dropIndexSuggestions：用户询问要删除什么或降低索引开销时使用。
22. schemaSuggestions：用户要求 schema/查询结构建议时使用。
23. 不要把 MCP 工具名作为 operations 的值传入，operations 是单独列出要获取哪些数据的参数。
24. 具体查询示例流程：先 collection-indexes 查看现有索引（如 {_id:1}、{status:1}、{date:-1}），再 explain（filter={status:'shipped',region:'US'}，sort={date:-1}，queryPlanner 与 executionStats），再 find limit=1 取样本文档推断 schema。
25. 若 Atlas 连接可用，从 MCP 连接串获取集群名或向用户询问 projectId/clusterName，用 slowQueryLogs 拉取过去 24 小时指定库表的慢查询，用 suggestedIndexes 检查索引建议。
26. 诊断：根据 explain 输出和慢查询日志判断问题，例如目标 100 条却扫描 5 万条索引项（选择性差 0.002）、内存排序带来开销、索引不支持全部过滤字段或排序。
27. 推荐：按 ESR 原则创建复合索引 {status:1, region:1, date:-1}（两个等值字段后接排序），消除内存排序并提升选择性。
28. 通用性能帮助流程：从连接串推断集群名并在 atlas-list-projects 中推断所需项目名，不确定时向用户询问集群名和 project id；用 slowQueryLogs 拉取过去 24 小时慢查询，并用 suggestedIndexes、dropIndexSuggestions、schemaSuggestions。
29. 诊断与推荐：根据慢查询日志和 Performance Advisor 建议给出优化，例如在 db.orders 上创建复合索引 {status:1, region:1, date:-1} 来优化 find({status:'shipped',region:'US'}).sort({date:-1}) 这类查询。
30. 检查所有 Performance Advisor 输出和慢查询日志，说明改进了什么及原因，聚焦影响最大的建议（影响查询最多的索引或性能最差的查询）。
31. 诊断和推荐前先加载参考文件：始终加载 references/core-indexing-principles.md 和 references/antipattern-examples.md。
32. 按条件加载：诊断聚合管道时加载 references/aggregation-optimization.md；诊断 replaceOne、findOneAndUpdate 等修改文档的查询时加载 references/update-query-examples.md（用于 oplog 高效更新和常见更新反模式）。
33. 输出保持简短清晰：用几句话说明索引和优化建议及理由（如通用索引原则、集群慢查询日志观察或 Performance Advisor 建议）。
34. 聚焦影响最大的索引或优化；若省略了某些优化，告知用户并在其要求时给出。
35. 不要使用强硬措辞（如“你应该创建这些索引，它们一定会提升应用性能”），应说明这些是针对特定查询的建议并给出理由。
36. 考虑集合上已有索引数量（若已知），一般不应超过 20 个。
37. 仅当建议来自 Atlas Performance Advisor 时才建议删除索引。
38. 除非用户批准，不要直接通过 MCP 创建索引。

适用边界 · 注意事项

• 用户只是常规编写 MongoDB 查询、未要求优化、慢查询或索引帮助时不要触发。
• 未配置 Atlas MCP Server 或无法确定正确集群时，无法做通用性能分析，应让用户配置或改为询问具体查询。
• 没有 MongoDB MCP Server 时无法直接获取索引/explain/样本文档，只能基于查询形态给出建议。