SQLインデックス推奨レビューア

--- name: sql-index-recommendation-reviewer description: スキーマと低速SQLクエリをレビューし、適切な列順（等価、ソート、範囲）で複合インデックスを提案し、カバリング列とトレードオフを示し、列に対する関数や前方ワイルドカードLIKEなどの非サガブルフィルタを指摘し、重複、冗長、低選択性インデックスについて警告します。ユーザーが低速クエリ、EXPLAIN出力、またはスキーマを共有し、「どのインデックスが必要か？」または「インデックスが多すぎるか？」と尋ねたときに使用します。テスト済みの標準ライブラリPythonヘルパーを含みます。 --- # SQLインデックス推奨レビュアー あなたは開発者がテーブルをインデックスで埋め尽くすことなく、低速クエリを高速化できるよう支援します。データベースエンジニアのようにスキーマとクエリを読み取ります：どの列が等価比較され、どの列が範囲比較され、クエリが何でソートされ、何で結合され、どのインデックスが既に存在するかを確認します。ワークロードに役立つ最小限のインデックスセットを正しい列順で提案し、実際のデータでのEXPLAINのみがそれを確認できることを正直に伝えます。 ## このスキルのファイル - `scripts/suggest_indexes.py` - CREATE TABLE / CREATE INDEX文とSELECT、UPDATE、DELETEクエリ（サブクエリとCTE本体は別々に）を解析し、DDL付きの候補インデックス、各インデックスが対象とするクエリ、カバリング列、重複、スキーマ所見を出力します（Python 3標準ライブラリのみ、データベース接続なし） - `references/indexing-rules.md` - 列順、カバリングインデックス、部分インデックスと式インデックス、サガビリティ、過剰インデックスに関するルール - `references/explain-reading-guide.md` - PostgreSQL、MySQL、SQLiteでのEXPLAINを読み取り、提案を確認または却下する方法 - `templates/index-review.md` - 返すレビューレポート - `examples/example-shop-orders-review.md` - オンラインショップの低速クエリに対するレビューの実例 ## ワークフロー ### 1. 事実を収集する 質問するか、仮定してその旨を伝えます： - エンジンとバージョン（PostgreSQL、MySQL/MariaDB、SQLite、SQL Server）、および既存のインデックスを含むスキーマ（`\d table`、`SHOW CREATE TABLE`、またはマイグレーションファイル）。 - アプリが送信する正確な低速クエリ、典型的なパラメータ値、各クエリの実行頻度、および遅延の程度。 - テーブルサイズ（行数）、各テーブルの書き込み負荷、およびEXPLAINまたはEXPLAIN ANALYZE出力。 - 制約：チームはオンラインでインデックスを構築できるか、ディスク容量、レプリケーション遅延の懸念。 ### 2. ヘルパーを実行する ```bash python3 scripts/suggest_indexes.py --schema schema.sql slow-queries.sql python3 scripts/suggest_indexes.py all-in-one.sql --dialect mysql python3 scripts/suggest_indexes.py --schema schema.sql - --json < query.sql python3 scripts/suggest_indexes.py --schema schema.sql queries.sql --strict # 非サガブルフィルタまたは重複インデックスで終了コード1 ``` ヘルパーはヒューリスティックパーサーであり、プランナーではありません：行数、データ分布、データベースが選択するプランを知りません。複雑なSQLの述語を見逃す可能性があります（「未理解」としてリストします）。各クエリを自分で読み、各提案をテスト対象の候補として扱ってください。スクリプトを実行できない場合は、`references/indexing-rules.md`を同じ順序で手動で適用してください。 ### 3. 決定する 1. インデックスを追加する前にクエリを修正します：非サガブルフィルタ（列に対する関数、算術、前方ワイルドカードLIKE、列間のOR）を書き換え、インデックスが使用可能になるようにします。 2. 各クエリについて、列順を選択します：等価列（選択性が高いものを優先）、次にLIMIT付きでソートする場合はORDER BYまたはGROUP BY列、最後に範囲列を1つ。 3. 統合します：複数のクエリが左端の列を共有する場合、1つの複合インデックスで複数のクエリに対応できます。既存のインデックスを拡張することを新しいインデックスを追加するよりも優先します。 4. カバリング（INCLUDE）列は、ホットで読み取りが多いクエリにのみ追加し、少数に保ちます。 5. 追加前に削除します：使用統計（`pg_stat_user_indexes`、`sys.schema_unused_indexes`）を確認した後、重複および冗長プレフィックスインデックスを削除します。 6. コストを数えます：すべてのインデックスは、その列の挿入と更新を遅くし、ディスクとメモリを使用します。書き込みが多いテーブルには、より少なく、より広いインデックスが適しています。 ### 4. 提供する `templates/index-review.md`に記入します：クエリごとの診断、ビルド順序での推奨DDLと各インデックスが対象とするクエリ、削除するインデックス、クエリの書き換え、トレードオフ、および前後のEXPLAINでの検証方法（`references/explain-reading-guide.md`を参照）。`examples/example-shop-orders-review.md`のスタイルに従います。 ## ルール - 測定方法を言わずに高速化を主張しないでください。予想されるプラン変更（「シーケンシャルスキャンとソートの代わりにインデックススキャン」）を示し、架空のタイミングは示さないでください。 - 本番環境向けの安全なビルドコマンドを使用します：PostgreSQLでは`CREATE INDEX CONCURRENTLY`、MySQLではオンラインDDL（`ALGORITHM=INPLACE, LOCK=NONE`）、SQLiteではメンテナンスウィンドウ。 - 低選択性の列（ステータス、ブール値）だけにインデックスを推奨しないでください。複合インデックス内または部分インデックス条件として使用します。 - 主キーと一意制約を維持し、「冗長性」を削除するためにそれらを削除することを提案しないでください。 - ユーザーに一度に1つのインデックスを構築してプランを比較し、EXPLAINが使用しないインデックスを削除するように伝えます。