遅い SQL クエリを最適化するプロンプト
いつ使うか
本番で n 秒かかるクエリ、EXPLAIN を見ても何が悪いか分からない時。Index 設計・JOIN 順・サブクエリの書き換え・適切な集計タイミングを AI に体系的に検討させたい時に使う。MySQL / PostgreSQL / SQLite どれでも応用可。
プロンプト本文 (コピペして使う)
あなたはデータベースパフォーマンスの専門家です。以下の SQL クエリを最適化してください。
## DBMS
<MySQL 8 / PostgreSQL 15 / SQLite など>
## 対象クエリ
```sql
<SQL を貼る>
```
## EXPLAIN 結果
```
<EXPLAIN / EXPLAIN ANALYZE の出力を貼る>
```
## テーブル定義 (関連分のみ)
```sql
<CREATE TABLE と既存 INDEX を貼る>
```
## 周辺情報
- レコード規模: <例: orders 500万、users 30万>
- 実行頻度: <例: API リクエストごとに10回>
- 許容レイテンシ: <例: p99 200ms>
## 分析フレーム
1. **EXPLAIN のボトルネック特定** (filesort / temporary / 全件スキャン箇所)
2. **既存 INDEX の評価** (使われているか、selectivity は十分か)
3. **必要な INDEX 追加案** (複合 index の列順含む)
4. **クエリ書き換え案** (サブクエリ→JOIN、CTE 化、EXISTS への置換)
5. **集計タイミング** (即時計算→summary テーブル/マテリアライズドビューへの逃がし)
## 出力
1. 一次原因 (3つまで、それぞれ EXPLAIN のどの行が根拠か)
2. 改善後の SQL
3. 追加すべき INDEX (CREATE INDEX 文)
4. 期待される効果と確認方法 (EXPLAIN で何が変わるか)
5. やってはいけないこと (例: SELECT * のままインデックスだけ追加するなど)
## 制約
- 推測ではなく EXPLAIN を根拠にする
- 書き込み頻度が高いテーブルへの過剰 INDEX 追加は注意点として明示効くポイント
- EXPLAIN を必ず一緒に渡すと、AI が推測でアドバイスしなくなる
- 「やってはいけないこと」を要求すると、INDEX 過剰追加のような副作用を回避できる
- 確認方法まで含めると、最適化が本当に効いたか後追いできる
よくある質問
- EXPLAIN ANALYZE は必須ですか?
- 必須ではないですが、貼ると AI が推測でアドバイスする割合が大幅に下がります。PostgreSQL なら EXPLAIN (ANALYZE, BUFFERS)、MySQL なら EXPLAIN ANALYZE を取って貼ることを推奨します。
- INDEX を追加するだけの提案が返ってきます
- INDEX 追加は INSERT/UPDATE のパフォーマンスを下げる副作用があるため、プロンプトの「やってはいけないこと」セクションに「INDEX の無条件追加提案は不可。追加する場合は副作用と保守コストも提示する」と明記してください。
- 対象テーブルの定義をどこまで貼ればいいですか?
- 対象クエリで参照しているテーブルと、その JOIN 先テーブルの CREATE TABLE と既存 INDEX 定義を貼れば十分です。それ以外のテーブルは省略してOKです。
- MySQL と PostgreSQL でプロンプトを変える必要は?
- プロンプトの「DBMS」セクションで指定すれば、AI が方言差 (INDEX HINT 構文・JSON 演算子・ウィンドウ関数のサポート差) を考慮した提案を返します。明示しないと曖昧な回答になりがちです。
このプロンプトを実戦で使った所感や改善案があればぜひフィードバックを。姉妹サイト ai-pick.tech では AI x SNS集客の運用ノウハウを公開しています。