supabase-postgres-best-practices
Postgres のパフォーマンスを専門家のベストプラクティスで最適化
こちらからも入手できます: supabase
低速なクエリと不十分なスキーマ設計は Postgres アプリケーションを悩ませます。このスキルは、10-1000 倍のパフォーマンス改善を達成するための Supabase 専門家による 26 個の優先順位付けされたルールを提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「supabase-postgres-best-practices」を使用しています。 Postgres クエリをレビューし、ベストプラクティスに基づいて最適化を提案してください： SELECT * FROM events WHERE user_id = 123 ORDER BY created_at DESC LIMIT 20
期待される結果:
query-missing-indexes.md ルールに基づくと、クエリにはフィルタとオーダーカラムのインデックスが必要です：
1. 複合インデックスを追加：
```sql
CREATE INDEX events_user_id_created_at_idx
ON events (user_id, created_at DESC);
```
2. 予想される改善：インデックススキャンにより、コストが 25,000 から 8.44 に削減されます（大規模テーブルでは 100-1000 倍高速）。
3. LIMIT クエリの場合、特定のカラムのみが必要な場合はカバリングインデックスを使用してテーブルルックアップを回避することを検討してください。
「supabase-postgres-best-practices」を使用しています。 このバッチ挿入パターンはベストプラクティスに従っていますか？ for (let i = 0; i < 1000; i++) { await db.query('INSERT INTO logs (message) VALUES ($1)', [logs[i]]); }
期待される結果:
いいえ、これは data-batch-inserts.md ルールに違反しています：
- 1000 回の個別のラウンドトリップ
- 1000 回の個別のトランザクション
- 必要よりも 10-50 倍遅いと推定
正しいアプローチ（ルールより）：
```sql
INSERT INTO logs (message) VALUES
($1), ($2), ($3), ... 最大約 1000 行;
```
または、大量インポートには COPY を使用します（最速の方法）。例については data-batch-inserts.md を参照してください。
「supabase-postgres-best-practices」を使用しています。 たまにクエリされるこの外部キーカラムにインデックスを追加すべきですか？
期待される結果:
はい、絶対に追加すべきです。schema-foreign-key-indexes.md によると：
**影響度：重大（5-20 倍の改善）**
外部キーカラムはほぼ常にインデックス化するべきです。理由は以下の通り：
1. 外部キーの JOIN はインデックスがないと順次スキャンを引き起こす
2. 親テーブルの DELETE は子テーブルのスキャンを必要とする
3. 大規模テーブルでは、カスケード操作が指数関数的に遅くなる
ルールでは：たまにしかクエリされない場合でも、外部キーのインデックス化は指数関数的なスキャンコストにより恩恵があると明記されています。
セキュリティ監査
安全All 710 static findings are false positives. This is a documentation-only skill containing Postgres best practices in Markdown format. The flagged patterns (backticks, MD5 references, URLs, system queries) are all legitimate SQL examples, documentation links, and monitoring queries. No executable code, no data exfiltration, no malicious intent detected.
中リスクの問題 (1)
低リスクの問題 (4)
リスク要因
⚡ スクリプトを含む (1)
🌐 ネットワークアクセス (2)
品質スコア
作れるもの
クエリパフォーマンスのトラブルシューティング
低速な API エンドポイントに直面している開発者が、クエリ最適化ルールを使用してインデックスを追加し、クエリを書き換えて 100-1000 倍の改善を達成します。
データベーススキーマ設計レビュー
データベースアーキテクトが高コストなリファクタリングを回避するために、マルチテナント SaaS アプリケーションのローンチ前にスキーマ設計ルールをレビューします。
Postgres 移行計画
DevOps エンジニアが RLS と接続プーリングガイドラインを使用して、シングルテナントからマルチテナントアーキテクチャへの移行を計画します。
これらのプロンプトを試す
遅い Postgres クエリがあります。supabase-postgres-best-practices スキルからベストプラクティスを使用して最適化するのを手伝ってください。 私のクエリ： ```sql SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending' ``` テーブルには 1000 万行があります。クエリは 5 秒かかります。
supabase-postgres-best-practices スキルを使用して、このスキーマのインデックス戦略をレビューしてください。複合インデックス、部分インデックス、外部キーインデックスに焦点を当ててください。 スキーマ： - users テーブル（100 万行） - orders テーブル（500 万行、users への外部キー） - クエリパターン：よく user_id + created_at + status でフィルタリング
supabase-postgres-best-practices を使用して、マルチテナントデータに行レベルセキュリティを実装しています。RLS ポリシーを最適化するのを手伝ってください。 現在のポリシー： ```sql CREATE POLICY user_isolation ON documents USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id); ``` RLS を有効にした後、クエリパフォーマンスが 5 倍低下しました。
supabase-postgres-best-practices を使用して、Supabase を使用した Node.js アプリケーションの接続プーリング設定を手伝ってください。 要件： - 1000 同時ユーザー - 平均クエリ時間：50ms - PgBouncer を使用 - 接続枯渇エラーが発生 具体的な設定値を提供し、トレードオフを説明してください。
ベストプラクティス
- 本番デプロイ前に、WHERE、JOIN、ORDER BY カラムのインデックスを常に作成する
- 大規模な結果セットでは、OFFSET の代わりにインデックス付きカラムでカーソルベースのページネーションを使用する
- ロック競合を防ぐために、トランザクションを短く（1 秒未満）保ち、トランザクション中のユーザー対話を避ける
回避
- 特定のカラムのみが必要な場合に、大規模テーブルで SELECT * を使用すること（不要な I/O を引き起こし、カバリングインデックス最適化を妨げる）
- 行をバッチ処理したり COPY を使用したりする代わりに、ループ内で個別の INSERT 文を実行すること
- EXPLAIN ANALYZE でクエリパターンを分析せずにインデックスを作成すること（一部のインデックスは読み取りの役に立たず、書き込みパフォーマンスを損なう可能性がある）