mcpField
L
ln-812-query-optimizer

ln-812-query-optimizer

github.com/levnikolaevichデータ・データベース58435 回インストール2 日前に更新
リポジトリ

ln-812-query-optimizer について

コード保守向けのクエリ最適化スキルです。監査結果または指定ファイルから非効率なクエリを特定し、変更ごとにテストして採用または差し戻しを判断し、修正レポートを作成します。

主な機能

  1. 01監査結果の読み込みまたは対象ファイルの調査
  2. 02影響度に基づく対応順の決定
  3. 03N+1、重複取得、過剰取得の修正
  4. 04テスト結果に基づく採用または差し戻し
  5. 05修正内容と失敗理由の報告

活用シーン

  1. 01クエリ効率監査で見つかった問題への対応
  2. 02リクエストのホットパスにある N+1 の最適化
  3. 03重複取得や不要なフィールド取得の削減

インストール

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

$npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-812-query-optimizer

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

詳細

パス： ファイルパス（shared/、references/、../ln-*）は、skills リポジトリのルートからの相対パスです。CWD に見つからない場合は、この SKILL.md があるディレクトリを見つけ、1 つ上の階層をリポジトリのルートとして参照してください。

ln-812-query-optimizer

タイプ： L3 Worker カテゴリ： 8XX 最適化 親： ln-810-performance-optimization-coordinator

ln-651-query-efficiency-auditor が検出したクエリ効率の問題を修正します。各修正は、採用／破棄のパターンを用いてテストで検証します。指標はクエリ数の削減です（実行時間のベンチマークではありません）。

概要

項目詳細
入力docs/project/persistence_audit.md（ln-651 のセクション）の監査結果、または対象ファイル
出力最適化されたクエリ、検証レポート
連携先ln-651-query-efficiency-auditor（問題を検出）→ ln-812（問題を修正）

ワークフロー

フェーズ： 事前確認 → 検出結果の読み込み → 優先順位付け → 修正ループ → レポート

フェーズ 0：事前確認

確認項目必須不足している場合の対応
監査結果または対象ファイルはい最適化をブロック
テスト基盤はいブロック（検証にはテストが必要）
Git のクリーンな状態はいブロック（差し戻し用のクリーンなベースラインが必要）

必ず読むこと： shared/references/ci_tool_detection.md を読み込み、テストの検出には Test Frameworks セクションを使用してください。

ワークツリーとブランチの分離

必ず読むこと： shared/references/git_worktree_fallback.md を読み込み、ln-812 の行を使用してください。

フェーズ 1：検出結果の読み込み

監査レポートから読み込む場合

docs/project/persistence_audit.md を読み込み、ln-651 の検出結果を抽出します。

検出タイプ最適化
N+1 クエリバッチ読み込み／イーガーローディング／.Include()／prefetch_related
重複した取得ID の代わりにオブジェクトを渡す、結果をキャッシュする
過剰なデータ取得必要なフィールドのみ選択する／プロジェクション／.Select()
インデックスヒントの不足インデックスのアノテーション／マイグレーションを追加する
上限のないクエリ.Take()／LIMIT／ページネーションを追加する
対象ファイルから読み込む場合

監査レポートがない場合は、対象ファイルをスキャンし、上の表に該当するクエリパターンを探します。

フェーズ 2：修正の優先順位付け

優先度基準
1（最高）ホットパス（リクエストごとに呼び出される箇所）の N+1
2重複した取得（同じエンティティが複数回読み込まれる）
3過剰なデータ取得（必要なカラムが少数なのに SELECT * を使用）
4ユーザー向けエンドポイントのページネーション不足

フェーズ 3：修正ループ（採用／破棄）

修正ごとのサイクル
FOR each finding (F1..FN):
  1. APPLY: Edit query code (surgical change)
  2. VERIFY: Run tests
     IF tests FAIL → DISCARD (revert) → next finding
  3. VERIFY: Tests PASS → KEEP
  4. LOG: Record fix for report
採用／破棄の判断
条件判断
影響を受けるファイル／関数をカバーするテストがない検出項目をスキップ — 「未カバー、スキップ」として記録
テストに合格する採用
テストに失敗する破棄し、失敗理由を記録
修正によって新たな N+1 が発生する破棄

注： ベンチマークは不要です。クエリ最適化の指標は、正しさ（テストに合格すること）と構造上の改善（クエリが減ること）です。非効率な箇所はすでに監査で特定されています。

フェーズ 4：結果のレポート

レポートスキーマ
フィールド説明
source監査レポートのパスまたは対象ファイル
findings_total監査で検出された項目の合計
fixes_applied正常に採用された修正
fixes_discarded理由を添えて破棄された修正
fix_details[]修正ごとの詳細：検出タイプ、ファイル、修正前／修正後の説明

設定

Options:
  # Source
  audit_report: "docs/project/persistence_audit.md"
  target_file: ""               # Alternative to audit report

  # Verification
  run_tests: true

  # Scope
  fix_types:                    # Filter which types to fix
    - n_plus_one
    - redundant_fetch
    - over_fetching
    - unbounded_query

エラー処理

エラー原因解決策
監査結果がないln-651 が実行されていない、または問題がない「最適化する検出項目なし」と報告する
ORM 固有の構文ORM が不明ORM のドキュメントを Context7/Ref で検索する
マイグレーションが必要インデックスの追加にマイグレーションが必要手動作業として記録し、スキップする

参考資料

  • ../ln-651-query-efficiency-auditor/SKILL.md（連携先：問題を検出）
  • shared/references/ci_tool_detection.md（テストの検出）

完了の定義

  • 監査レポートまたは対象ファイルのスキャンから検出事項を読み込みます
  • 修正に優先順位を付けます（まず N+1、その後に冗長なクエリ、過剰な取得、上限のないクエリ）
  • 各修正を適用し、採用または破棄します。テストに合格した場合は採用し、失敗した場合は破棄します
  • 修正によって新たなクエリの非効率性を生じさせません
  • 検出事項の合計数、適用した修正、破棄した修正を含むレポートを返します

バージョン： 1.0.0 最終更新日： 2026-03-08

コメント

Markdown 対応