쿼리 분석 워크플로우

쿼리가 예상보다 오래 걸리면 다음 단계에 따라 쿼리 성능에 부정적인 영향을 미칠 수 있는 문제를 찾아 교정합니다. 시스템에서 튜닝을 통해 성능을 높일 수 있는 쿼리에 대해 확신이 없는 경우에는 먼저 튜닝에 가장 적합한 쿼리 식별 섹션의 진단 코드를 실행하세요.

1. 테이블이 모범 사례에 따라 설계되어 있는지 확인합니다. 자세한 내용은 Amazon Redshift 테이블 설계 모범 사례 섹션을 참조하세요.

2. 테이블에서 불필요한 데이터를 삭제하거나 아카이빙할 수 있는지 살펴봅니다. 예를 들어 쿼리가 항상 지난 6개월 분량의 데이터를 대상으로 하지만 테이블에는 지난 18개월 분량의 데이터가 저장되어 있다고 가정하겠습니다. 이러한 경우 이전 데이터를 삭제하거나 아카이브하여 스캔 및 분산해야 하는 레코드 수를 줄일 수 있습니다.

3. 쿼리에서 테이블에 대한 VACUUM 명령을 실행하여 공간을 회수한 다음 행을 재정렬합니다. 정렬되지 않은 영역이 크고, 쿼리가 조인 또는 조건자에서 정렬 키를 사용하는 경우, VACUUM을 실행하는 것이 좋습니다.

4. 쿼리에서 테이블에 대한 ANALYZE 명령을 실행하여 통계를 최신 상태로 유지합니다. 쿼리에서 테이블 하나라도 최근에 크기가 많이 변경된 경우에는 ANALYZE를 실행하는 것이 좋습니다. ANALYZE 명령 전체를 실행하는 데 시간이 너무 오래 걸린다면 단일 열에 대한 ANALYZE를 실행하여 처리 시간을 줄일 수 있습니다. 이러한 방법으로도 테이블 크기 통계가 업데이트됩니다. 테이블 크기는 쿼리 계획에서 중요한 요인입니다.

5. 각 유형별 클라이언트에 따라(클라이언트가 사용하는 연결 프로토콜 유형에 따라) 쿼리를 한 번씩 실행해야만 쿼리가 컴파일 및 캐싱됩니다. 그러면 이후 쿼리를 실행하는 속도가 빨라집니다. 자세한 내용은 쿼리 성능에 영향을 미치는 요인 섹션을 참조하세요.

6. STL_ALERT_EVENT_LOG 테이블을 확인하고 쿼리의 잠재적 문제를 찾아 교정합니다. 자세한 내용은 쿼리 알림 검토 섹션을 참조하세요.

7. EXPLAIN 명령을 실행하여 쿼리 계획을 가져와 쿼리를 최적화하는 데 사용합니다. 자세한 내용은 쿼리 계획 분석 섹션을 참조하세요.

8. SVL_QUERY_SUMMARY 및 SVL_QUERY_REPORT 뷰를 사용하여 요약 정보를 가져와 쿼리를 최적화하는 데 사용합니다. 자세한 내용은 쿼리 요약 분석 섹션을 참조하세요.

간혹 빠르게 실행해야 하데 다른 장기 실행 쿼리가 끝날 때까지 기다려야 하는 쿼리가 있는 경우도 있습니다. 이때는 쿼리 자체에서 개선할 방법은 없습니다. 하지만 쿼리 유형마다 다른 쿼리 대기열을 생성 및 사용하여 전체 시스템 성능을 높일 수는 있습니다. 쿼리 대기열의 대기 시간에 대한 자세한 내용은 쿼리의 대기열 대기 시간 검토 섹션을 참조하세요. 상태 확인 구성에 대한 자세한 내용은 워크로드 관리 구현 섹션을 참조하세요.