mcpField
M
mongodb-query-optimizer

mongodb-query-optimizer

github.com/mongodbデータ・データベース1927.2k 回インストール1 週間前に更新
リポジトリ

mongodb-query-optimizer について

MongoDB のクエリやインデックスの最適化、スロークエリの調査を行うユーザー向けのスキルです。クエリプラン、既存インデックス、Atlas Performance Advisor の情報を基に診断し、承認なしにインデックスを作成しません。

主な機能

  1. 01クエリプランと実行統計の分析
  2. 02コレクションの既存インデックス確認
  3. 03Atlas のスロークエリと提案の取得
  4. 04ワークロードに基づくインデックス提案
  5. 05クエリ別の参考資料読み込み

活用シーン

  1. 01MongoDB クエリが遅い原因の診断
  2. 02フィルターとソートに適した複合インデックスの評価
  3. 03クラスターのスロークエリと Atlas 提案の確認
  4. 04更新操作や集約パイプラインの最適化案の検討

MCP 対応

MongoDB MCP サーバーのデータベースおよび Atlas ツールを呼び出し、インデックス、クエリプラン、サンプル文書、Performance Advisor の情報を取得します。結果に基づいて最適化案を提示し、ユーザーの承認なしに MCP 経由でインデックスを作成することはありません。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mongodb/agent-skills --skill mongodb-query-optimizer

インストール後、Claude Code で/mongodb-query-optimizerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
aggregation-optimization.md
antipattern-examples.md
core-indexing-principles.md
update-query-examples.md

詳細

MongoDB クエリ最適化

このスキルを呼び出す場合

ユーザーが次のことを求めている場合に限り呼び出します。

  • クエリ/インデックスの最適化またはパフォーマンスに関するサポート
  • クエリが遅い理由、または高速化する方法
  • クラスター上の低速クエリに関する情報、および/または最適化する方法

最適化、低速クエリ、またはインデックス作成に関するサポートをユーザーが求めていない限り、通常のクエリ作成では呼び出さないでください。

ワークフローの概要

一般的なパフォーマンスに関するサポート

ユーザーが低速クエリの調査を希望する場合、または特定のクエリに関するものではない一般的なパフォーマンス改善の提案を求めている場合:

  • MongoDB MCP サーバーの atlas-get-performance-advisor ツールを使用して、低速クエリログとパフォーマンスアドバイザーの出力を取得します
  • この情報に基づいて提案します

Atlas 用の Atlas MCP Server が設定されていない場合、または正しいクラスターに対して atlas-get-performance-advisor を実行するための情報が不足している場合は、一般的なパフォーマンス分析には API 認証情報を使用した Atlas MCP Server の設定が必要であることをユーザーに伝え、設定するか、特定のクエリについて質問するよう提案します。

特定のクエリに関するサポート

ユーザーが特定のクエリについて質問している場合:

  • collection-indexes、explain、find MCP ツールを使用して、コレクションに既存のインデックスがあるか、クエリの explain() 出力、およびコレクションのサンプルドキュメントを取得します
  • atlas-get-performance-advisor MCP ツールを使用して、低速クエリログとパフォーマンスアドバイザーの出力を取得します

収集した情報、MongoDB のベストプラクティス、およびリファレンスファイルの例に基づいて最適化を提案します。可能であれば、クエリを完全にカバーするインデックスの作成を優先します。MongoDB MCP Server を使用できない場合も、提案を試みてください。

MCP:利用可能なツール

呼び出し方法。 toolName に正確なツール名を指定し、arguments に単一の引数オブジェクトを指定して、MongoDB MCP server を呼び出します。ツール名をオプション、クエリパラメーター、またはネストされたキーとして渡さないでください。MCP ツール名として指定し、パラメーターは引数オブジェクトとして渡します。MCP Server のツールリファレンス全文:MongoDB MCP Server Tools。

データベースツール(MCP クラスター接続が機能している場合):

ツール名(正確な名前)引数オブジェクト
collection-indexes{ "database": "<db>", "collection": "<coll>" } — 両方とも必須の文字列です。
explain{ "database": "<db>", "collection": "<coll>", "method": [ { "name": "find", "arguments": { "filter": {...}, "sort": {...}, "limit": N } } ], "verbosity": "executionStats" }。method は 1 つのオブジェクトを含む配列です。name は "find"、"aggregate"、または "count"、arguments にはそのメソッドのパラメーター(例:find の場合は filter、sort、limit、aggregate の場合は pipeline、count の場合は query)を指定します。verbosity は省略可能です。指定できる値は "queryPlanner"(デフォルト)、"executionStats"、"queryPlannerExtended"、"allPlansExecution" です。
find{ "database": "<db>", "collection": "<coll>", "filter": {...}, "projection": {...}, "sort": {...}, "limit": N } — database、collection、filter は必須です。projection、sort、limit は省略可能です。

Atlas ツール(Atlas API 認証情報が設定されている場合):

ツール名(正確な名前)引数オブジェクト
atlas-list-projects{} または { "orgId": "<24-char hex>" }。ID を含むプロジェクトを返します。Performance Advisor 用の projectId を取得するために使用します。
atlas-get-performance-advisor必須: "projectId"(24 文字の 16 進数文字列)、"clusterName"(文字列、1~64 文字の英数字/アンダースコア/ダッシュ)。省略可能: "operations" — "suggestedIndexes"、"dropIndexSuggestions"、"slowQueryLogs"、"schemaSuggestions" から選ぶ文字列の配列(必要なものだけをリクエストしてください)。slowQueryLogs の場合のみ:"since"(ISO 8601 の日時)、"namespaces"("db.coll" 形式の文字列の配列)。

ユーザーからの質問に答える際は、最適化対象のクエリに関連する情報を、接続文字列と Atlas API の両方から取得するよう試みてください。

1. MongoDB MCP でデータベース接続文字列が機能する

一般的な流れ:collection-indexes → explain → find(サンプルドキュメント)の順に呼び出します。

  • collection-indexes — 結果の classicIndexes(それぞれに name と key があります)を使用して、クエリが既存のインデックスを利用できるか確認します。
  • explain — まず "queryPlanner" モードで実行し、COLLSCAN が発生していないか確認します。クエリがインデックスを使用している場合、またはコレクションが非常に小さい場合は、再度 "executionStats" で実行します(タイムアウトは10秒)。これにより、スキャンしたドキュメント数と返されたドキュメント数を確認できます。
2. MongoDB MCP で Atlas API にアクセスできる

プロジェクト ID が必要な場合は、まず atlas-list-projects を呼び出します。次に、必要な operations のみを指定して atlas-get-performance-advisor を呼び出します。

Operation の値使用する状況
slowQueryLogs低速クエリを取得する場合—最も低速で頻度の高いものを優先します。オプション:コレクションを絞り込む namespaces、対象期間を指定する since。
suggestedIndexesクラスターのインデックスに関する推奨事項を取得する場合
dropIndexSuggestionsユーザーが削除対象、またはインデックスのオーバーヘッドを減らす方法を尋ねた場合
schemaSuggestionsインデックスに加えて、スキーマやクエリ構造に関するアドバイスをユーザーが求めた場合

取得するデータを指定する operations は独立した引数です。MCP ツール名を operations の値として渡さないでください。

ワークフロー例 1(特定のクエリに関するサポート)

ユーザー:「このクエリが遅いのはなぜですか? db.orders.find({status: 'shipped', region: 'US'}).sort({date: -1})」

MCP のデータベース接続が構成済みで、データベース名とコレクション名が分かっている場合は、手順 1~3 を実行します。それ以外の場合は手順 4 に進みます。

  1. 既存のコレクションインデックスを確認します:

    • database=store、collection=orders を指定して collection-indexes を呼び出します
    • 結果には {_id: 1}、{status: 1}、{date: -1} が表示されます
  2. explain を実行します:

    • method=find、filter={status: 'shipped', region: 'US'}、sort={date: -1}、verbosity=queryPlanner および executionStats を指定して explain を呼び出します
    • 結果:{status: 1} インデックスが使用され、その後インメモリ SORT が実行されます。totalKeysExamined: 50000、nReturned: 100 です
  3. find を実行します:

    • limit=1 を指定して find を呼び出し、スキーマを推定するためのサンプルドキュメントを取得します。

MCP の Atlas 接続が構成済みの場合は、手順 4 を実行します。それ以外の場合は手順 5 に進みます。

  1. atlas-get-performance-advisor を実行します:

    • MCP 接続文字列からクラスター名を取得するか、projectId/clusterName をユーザーに尋ねます
    • slowQueryLogs を使用して、過去24時間の database=store、collection=orders の低速クエリログを取得します
    • suggestedIndexes を使用して、このクエリに対するインデックスの推奨事項を確認します
  2. 診断します: explain の出力と低速クエリログに基づくと、このクエリは100件のドキュメントを対象としていますが、インデックスエントリを50K件スキャンしています(選択性が低く、0.002です)。インメモリソートによってオーバーヘッドが発生しています。このインデックスは、両方のフィルターフィールドとソートをサポートしていません。

  3. 推奨します: ESR に従って、複合インデックス {status: 1, region: 1, date: -1} を作成します(等価条件のフィールドを2つ、その後にソート)。これにより、インメモリソートがなくなり、status と region の両方でフィルタリングすることで選択性が向上します。

MongoDB MCP サーバーがセットアップされていない場合は、インデックス作成のベストプラクティスに従ってください。

ワークフロー例 2(一般的なデータベースのパフォーマンスに関するサポート)

ユーザー:「クラスターで遅いクエリを最適化する方法を教えてもらえますか?」

  1. atlas-get-performance-advisor を実行する:
    • 接続文字列からクラスター名を取得し、atlas-list-projects で必要なプロジェクト名を推測してみてください。不明な場合は、ユーザーにクラスター名とプロジェクト ID を尋ねてください。
    • slowQueryLogs を使用して、過去 24 時間の遅いクエリログを取得します。
    • suggestedIndexes を使用します。
    • dropIndexSuggestions を使用します。
    • schemaSuggestions を使用します。
  2. 診断して提案する: 遅いクエリログと Performance Advisor のアドバイスに基づき、db.orders コレクションに複合インデックス {status: 1, region: 1, date: -1} を作成して、find({status: 'shipped', region: 'US'}).sort({date: -1}) などのクエリを最適化できます。

Performance Advisor の出力と遅いクエリログをすべて確認してください。何が、なぜ改善されるのかを説明し、最も大きな効果が期待できる提案(たとえば、最も多くのクエリに影響するインデックスや、パフォーマンスが最も悪いクエリ)に重点を置いてください。

リファレンスを読み込む

診断と提案を始める前に、リファレンスファイルを読み込んでください。

必ず読み込むファイル:

  • references/core-indexing-principles.md
  • references/antipattern-examples.md

条件に応じて読み込むファイル:

  • 集計パイプラインを診断する場合 → references/aggregation-optimization.md
  • replaceOne、findOneAndUpdate など、ドキュメントを変更するクエリを診断する場合 → 効率的な oplog 更新と一般的な更新のアンチパターンについて、references/update-query-examples.md

出力

  • 回答は簡潔で分かりやすくします。インデックスや最適化の提案と、その根拠(一般的なインデックスの原則、クラスターの遅いクエリログの確認結果、Performance Advisor のアドバイスなど)を数文で説明します。
  • 最も効果の大きいインデックスや最適化に重点を置きます。一部の最適化を省略した場合は、その旨をユーザーに伝え、求められたら提示します。
  • 「これらのインデックスを作成すれば、アプリケーションのパフォーマンスは必ず向上します」のような断定的な表現は避けてください。特定のクエリに対する提案であることを説明し、提案の根拠を示してください。
  • コレクションにすでに存在するインデックスの数を考慮してください(分かる場合)。一般に、20 個を超えるべきではありません。
  • インデックスの削除は、Atlas Performance Advisor から提案された場合にのみ提案してください。
  • ユーザーの承認がない限り、MCP 経由でインデックスを直接作成しないでください。

コメント