デバッグ上級

SQL クエリのパフォーマンス改善

EXPLAIN 結果を読みながらインデックス追加やクエリ書き換えを提案するプロンプト。

監修: 平原尚樹

株式会社BlueAI 代表取締役CEO / ソフトウェアエンジニア / プロダクトエンジニア / Google Cloud Architect / 元AIスタートアップ(Doorkel)

監修: 酒井歩乃加

早稲田大学文化構想学部卒業 / フリーランス編集者・ライター / 元マイベスト編集ディレクター / SEO対策記事・取材記事執筆

こんな課題を解決

管理画面の一部ページが 3 秒以上かかっており、原因がスロークエリと判明した。EXPLAIN は出ているが読み方とインデックス設計に自信がない。

プロンプト

Claude Code に入力

次のスロークエリを改善してください。

## クエリ
```sql
[SELECT 文を貼り付け]
```

## EXPLAIN 結果
```
[EXPLAIN ANALYZE の出力を貼り付け]
```

## 環境
- DBMS: TiDB Serverless
- テーブル行数: leads 約 580 万行 / lp_visits 約 1200 万行
- 既存インデックス: [SHOW INDEX FROM leads の出力]

## 期待するアウトプット
1. ボトルネックの説明（フルスキャン / 不適切な join 順 / temp file ソート など）
2. 改善案を 3 つ提示し、それぞれのトレードオフ（書込負荷、容量）を比較
3. 推奨案の ALTER TABLE と書き換え後のクエリ
4. 改善前後の EXPLAIN 差分予測

## 守ること
- TiFlash にフォールバックさせない（USE INDEX を明示）
- インデックスはカバリングを意識
- COUNT(*) ではなく COUNT(column) を使う

実行結果の例

Claude Code が以下を返します。 - 原因: ORDER BY created_at が IndexFullScan、複合 idx 無し - 提案 A: (org_id, deleted_at, created_at) を追加 - 提案 B: keyset pagination に書き換え - 推奨 = A + USE INDEX ヒント、想定 3.2s → 120ms

コツ・ポイント

テーブルサイズと書込頻度を伝えるとインデックス選択が現実的になる
EXPLAIN ANALYZE の actual rows と estimated rows の乖離が手掛かり
TiDB は OR 条件で IndexMerge を選びやすいので注意
改善後はクエリだけでなくアプリ側のキャッシュ余地も検討させる