postgres-best-practices
PostgreSQLクエリとスキーマの最適化
遅いデータベースクエリやパフォーマンスの低下に悩んでいませんか？このスキルは、Supabaseでの実証済みのPostgreSQL最適化ルール、具体的なSQL例、および測定可能なパフォーマンス改善を提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「postgres-best-practices」を使用しています。 このクエリは100k行で5秒かかります: SELECT * FROM orders WHERE customer_id = 42 AND status = 'pending'
期待される結果:
複合インデックスを作成: CREATE INDEX idx_orders_customer_status ON orders (customer_id, status)。これにより実行プランがシーケンシャルスキャンからインデックススキャンに変更され、クエリ時間が10ms未満になります。列の順序重要です：最適なインデックス使用のために、等価フィルター（customer_id）をstatusフィルターの前に配置してください。
「postgres-best-practices」を使用しています。 ユーザープロファイルデータを含むユーザーを取得する際にN+1クエリを防ぐにはどうすればいいですか？
期待される結果:
個別のクエリをJOINに置き換えてください: SELECT u.*, p.bio, p.avatar_url FROM users u LEFT JOIN user_profiles p ON p.user_id = u.id。高速ルックアップのためにuser_profiles(user_id)にインデックスを追加してください。これにより101クエリ（ユーザープロファイル用の100を含む）が単一のクエリに削減されます。
セキュリティ監査
安全This skill contains educational documentation for PostgreSQL best practices from Supabase. All 711 static analysis findings are false positives: the 'external_commands' detections are SQL code blocks in markdown documentation (not shell commands), 'network' URLs are reference links to postgresql.org and supabase.com, 'scripts' findings are SQL WITH clauses (CTEs), and 'crypto' warnings are text pattern matches in documentation. No executable code or security risks present.
品質スコア
作れるもの
低速クエリを最適化するバックエンド開発者
欠落しているインデックスを特定し、N+1パターンを修正し、クエリ最適化技術を適用して、応答時間を秒からミリ秒に短縮します。
新しいスキーマを設計するデータベースアーキテクト
初期スキーマ設計時にデータ型、制約、外部キー、インデックス戦略のベストプラクティスを適用します。
本番データベースをチューンするDevOpsエンジニア
接続制限、バキューム設定、モニタリングを構成して、負荷下でのデータベース健全性を維持します。
これらのプロンプトを試す
Review this PostgreSQL query for performance issues and suggest improvements: [paste query]
Analyze this table schema and query workload. What indexes should I create for optimal performance? Schema: [paste schema], Queries: [paste queries]
I'm fetching users and their orders with separate queries. Show me how to rewrite this as a single efficient JOIN with proper indexing.
Create a Row-Level Security policy for a multi-tenant SaaS where users can only access data belonging to their organization. Table structure: [paste schema]
ベストプラクティス
- WHERE、JOIN、ORDER BY列には常にインデックスを追加する
- デプロイ前にEXPLAIN ANALYZEでクエリ実行プランを確認する
- データベースの枯渇を防ぐために接続プールを実装する
回避
- シーケンシャルスキャンを引き起こす大きなテーブルでの非インデックスクエリの実行
- 特定のフィールドの代わりにSELECT *ですべての列を取得する
- インデックス使用を妨げる先頭ワイルドカードを持つLIKEの使用
よくある質問
哪些列にインデックスが必要ですか？
N+1とは何ですか？またどのように修正しますか？
Row-Level Securityはどのように機能しますか？
インデックスを追加した後、なぜクエリが遅くなるのですか？
開発者の詳細
作成者
sickn33ライセンス
MIT
リポジトリ
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/postgres-best-practices参照
main