postgres-patterns
PostgreSQL 마이그레이션 검토 및 쿼리 최적화
Alembic은 PostgreSQL 성능 영향을 고려하지 않고 마이그레이션을 생성합니다. 이 스킬은 데이터베이스 마이그레이션을 검토하고 일반적인 성능 문제를 피하는 효율적인 쿼리 작성 패턴을 제공합니다.
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「postgres-patterns」。 Review this migration for PostgreSQL issues: op.add_column('users', sa.Column('bio', sa.Text(), nullable=False))
預期結果:
- 경고: 이 마이그레이션은 대용량 테이블에서 테이블을 잠급니다
- 문제: 기본값 없이 NOT NULL 컬럼을 추가하면 전체 테이블 재작성이 발생합니다
- 더 나은 접근법 (3단계 프로세스):
- 1. 먼저 nullable 컬럼 추가: ALTER TABLE users ADD COLUMN bio TEXT;
- 2. 긴 잠금을 피하기 위해 배치로 데이터 백필
- 3. 제약 조건 추가: ALTER TABLE users ALTER COLUMN bio SET NOT NULL;
- 추가: bio로 쿼리할 경우 인덱스 추가 고려
正在使用「postgres-patterns」。 Our users table has 10 million rows and queries are slow: SELECT * FROM users WHERE status = 'active' ORDER BY created_at DESC LIMIT 100;
預期結果:
- 활성 사용자만을 위한 부분 인덱스를 고려하세요:
- CREATE INDEX ix_users_active_status_created ON users (status, created_at) WHERE status = 'active';
- 이 인덱스는 status에 대한 전체 인덱스보다 훨씬 작습니다
- WHERE 절이 쿼리 필터와 정확히 일치합니다
- 특정 컬럼을 선택하는 경우 커버링 인덱스 추가도 고려하세요
安全審計
安全This is a pure documentation skill containing only PostgreSQL best practices. No executable code, network calls, file access, or external commands exist. The skill-report.json audit explicitly states risk_level: safe and safe_to_publish: true. All 81 static findings are false positives caused by the scanner misinterpreting SQL identifier backticks as shell execution and database terminology as malicious patterns.
風險因素
🌐 網路存取 (1)
⚙️ 外部命令 (41)
品質評分
你能建構什麼
마이그레이션 안전성 검토
배포 전에 새 마이그레이션의 테이블 잠금, 누락된 인덱스, 제약 조건 문제를 확인합니다.
쿼리 성능 최적화
느린 쿼리를 식별하고 부분 인덱스 및 JSONB 인덱스를 포함한 적절한 인덱싱 전략을 적용합니다.
데이터베이스 이슈 디버깅
진단 쿼리를 사용하여 연결 문제, 잠금 경합, 테이블 크기 이슈를 진단합니다.
試試這些提示
이 Alembic 마이그레이션의 PostgreSQL 이슈를 검토해주세요. 테이블 잠금, 누락된 인덱스, 제약 조건 문제를 확인해주세요: [마이그레이션 코드 붙여넣기]
이 쿼리가 느립니다. 쿼리가 특정 값으로 필터링하는 경우 부분 인덱스를 포함하여 적절한 인덱스를 설계해주세요: [쿼리 및 테이블 스키마 붙여넣기]
JSONB 쿼리가 느립니다. 이 패턴에 대한 적절한 GIN 인덱스 및 표현식 인덱스를 생성하는 방법을 보여주세요: [JSONB 쿼리 패턴 설명]
애플리케이션에서 잠금이 발생하고 있습니다. 차단 프로세스와 장기 실행 트랜잭션을 식별하는 진단 쿼리를 보여주세요: [증상 설명]
最佳實務
- 프로덕션 테이블에서는 항상 CREATE INDEX CONCURRENTLY를 사용하여 쓰기 잠금을 피하세요
- 행의 일부만 쿼리할 때는 부분 인덱스를 사용하여 인덱스를 작게 유지하세요
- 기존 테이블에 NOT NULL 컬럼을 추가할 때는 3단계 프로세스를 적용하세요
避免
- 프로덕션 데이터베이스에서 CONCURRENTLY 없이 CREATE INDEX 사용
- 낮은 카디널리티 컬럼(예: boolean 플래그)에만 인덱스 추가
- BRIN 인덱스나 인덱스 조각화를 고려하지 않고 uuid4를 기본 키로 사용