postgres-performance
PostgreSQL クエリパフォーマンスの最適化
データベースのパフォーマンス問題はアプリケーションを遅くし、ユーザーにフラストレーションを与えます。このスキルは、インデックス戦略、クエリチューニング、スケーラブルなアーキテクチャパターンを含む、PostgreSQL最適化の実証済みパターンを提供します。
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"postgres-performance" 사용 중입니다. My query SELECT * FROM events WHERE user_id = 'abc-123' ORDER BY created_at DESC LIMIT 10 is slow on a table with 5M rows.
예상 결과:
このクエリは大きな events テーブルで順次スキャンを実行している可能性があります。最適化アプローチは以下の通りです:
**問題:** フィルタと ORDER BY カラムのインデックスが欠落しています。
**解決策:** カバリングインデックスを作成します:
```sql
CREATE INDEX CONCURRENTLY ix_events_user_created
ON events (user_id, created_at DESC);
```
このインデックスにより以下が可能になります:
1. インデックスから直接 user_id でフィルタリング
2. インデックスの順序を使用して created_at DESC でソート
3. インデックス付きカラムのみを選択する場合、インデックスオンリースキャン
**検証:**
```sql
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM events
WHERE user_id = 'abc-123'
ORDER BY created_at DESC
LIMIT 10;
```
プランで「Seq Scan」ではなく「Index Scan」を確認してください。
"postgres-performance" 사용 중입니다. How should I implement pagination for a high-traffic API endpoint?
예상 결과:
大規模データセットには OFFSET ベースのページネーションを避けてください。代わりにカーソルベース(キーセット)ページネーションを使用してください。
**OFFSET が遅い理由:**
```sql
SELECT * FROM events ORDER BY created_at DESC LIMIT 20 OFFSET 10000;
-- 結果を返す前に 10,000 行をスキャンして破棄する必要があります
```
**カーソルベースのアプローチ:**
```sql
SELECT * FROM events
WHERE created_at < '2024-01-15T10:30:00Z'
ORDER BY created_at DESC
LIMIT 20;
-- インデックス経由で適切な場所に直接ジャンプします
```
**Python 実装:**
```python
async def get_events_page(session, cursor_time=None, limit=20):
query = select(Event).order_by(Event.created_at.desc())
if cursor_time:
query = query.where(Event.created_at < cursor_time)
return await session.execute(query.limit(limit))
```
**トレードオフ:**
- 任意のページ番号にジャンプできません
- クライアントにカーソルを渡す必要があります
- 深いページネーションではるかに高速です
보안 감사
낮은 위험Static analysis flagged 78 potential issues but all are false positives. The scanner misidentified SQL keywords as cryptographic code and markdown code fences as shell execution. This is a legitimate PostgreSQL performance optimization skill containing documentation and example queries. Risk factors are standard for documentation skills that include code examples.
품질 점수
만들 수 있는 것
アプリケーションの遅いクエリのデバッグ
PostgreSQL 診断ツールと EXPLAIN 分析を使用して、アプリケーションクエリのパフォーマンスボトルネックを特定し修正します。
スケーラブルなデータベーススキーマの設計
高スループットのデータベースワークロードに対して、インデックス戦略、パーティショニング、非正規化パターンを適用します。
バッチ操作の最適化
SKIP LOCKED を使用したバッチパターンで、ロックやタイムアウトを発生させずに大規模データセットを効率的に処理します。
이 프롬프트를 사용해 보세요
My PostgreSQL query is slow. Analyze and optimize it: ```sql SELECT * FROM orders WHERE user_id = ? AND status = 'pending' ORDER BY created_at DESC LIMIT 20; ``` How can I improve this query?
I need to optimize these frequently-run queries on a table with 10M+ rows: 1. SELECT * FROM products WHERE category_id = ? AND in_stock = true 2. SELECT id, name, price FROM products WHERE category_id = ? ORDER BY price ASC 3. SELECT COUNT(*) FROM products WHERE category_id = ? Design an optimal index strategy.
Our API uses OFFSET pagination and it is slow for deep pages:
```python
# Current implementation
def get_events(page: int, limit: int = 20):
offset = (page - 1) * limit
return db.execute("SELECT * FROM events ORDER BY created_at DESC LIMIT ? OFFSET ?", limit, offset)
```
Convert this to cursor-based pagination with example code.Configure PostgreSQL connection pooling for our use case: - Serverless Python API on Lambda (spiky traffic, ~1000 req/min) - We see connection errors during traffic spikes - Database has 16GB RAM, shared_buffers = 4GB What pool settings do you recommend?
모범 사례
- 変更前後で必ず EXPLAIN (ANALYZE, BUFFERS) を使用してクエリの改善を検証する
- 頻繁なクエリに対してヒープフェッチを避けるためにカバリングインデックス(INCLUDE 句)を使用する
- 100K 行を超えるテーブルには OFFSET の代わりにカーソルベースのページネーションを実装する
피하기
- パフォーマンスが重要なクエリで SELECT * を使用する - 必要なカラムのみを指定する
- バッチ処理なしで大規模な UPDATE または DELETE 操作を実行する - ロックとタイムアウトを引き起こす
- 並行バッチ処理で FOR UPDATE SKIP LOCKED パターンをスキップする