튜닝 관점

SQL은 네 단계를 거쳐 실행되고, 느린 이유도 단계마다 다르게 드러납니다.

먼저 실행 계획을 준비하고, 그다음 실제 데이터를 읽거나 전달합니다. 병목을 찾을 때는 어느 단계에서 비용이 커졌는지 구분해서 봐야 합니다.

1
Parse

구문 분석

문법, 객체 존재, 권한을 확인하고 같은 SQL이 이미 캐시에 있는지 먼저 찾습니다.

느리면 여기서 확인
Hard Parse가 반복되는지, 바인드 변수 없이 매번 새 SQL로 인식되는지 봅니다.
2
Optimize

최적화

옵티마이저가 인덱스 사용, 조인 순서, 접근 경로를 비교해 가장 비용이 낮은 실행 계획을 고릅니다.

느리면 여기서 확인
잘못된 실행 계획, 오래된 통계, 비효율적인 조인 순서를 의심합니다.
3
Execute

실행

선택된 계획대로 인덱스와 테이블에 접근하며 Buffer Cache 또는 디스크에서 실제 데이터를 읽고 씁니다.

느리면 여기서 확인
I/O 양이 과도한지, 풀 스캔이나 랜덤 접근이 불필요하게 많은지 봅니다.
4
Fetch

결과 반환

SELECT는 읽어 온 행을 애플리케이션으로 넘기고, 다른 명령은 처리 결과와 영향을 받은 건수를 반환합니다.

느리면 여기서 확인
반환 행 수가 너무 많은지, 네트워크 전송과 반복 Fetch가 응답 시간을 늘리는지 봅니다.
핵심 읽기 순서

1 캐시 재사용 여부 → 2 실행 계획 선택 → 3 실제 데이터 접근 비용 → 4 결과 반환량 순서로 보면, 왜 같은 SQL도 어떤 것은 빠르고 어떤 것은 느린지 더 빠르게 판단할 수 있습니다.