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 컬럼, 그 다음 하나의 범위 컬럼. 3. 병합: 하나의 복합 인덱스가 왼쪽 컬럼을 공유할 때 여러 쿼리를 처리할 수 있습니다. 새 인덱스를 추가하는 것보다 기존 인덱스를 확장하는 것을 선호합니다. 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에서 유지 관리 창. - 낮은 선택성 컬럼(상태, 부울)에 단독 인덱스를 권장하지 마십시오; 복합 인덱스 내부 또는 부분 인덱스 조건으로 사용하십시오. - 기본 키와 고유 제약 조건을 유지하십시오; "중복"을 제거하기 위해 삭제를 제안하지 마십시오. - 사용자에게 한 번에 하나의 인덱스를 구축하고 계획을 비교하며, EXPLAIN이 사용하지 않는 인덱스를 제거하라고 말하십시오.