실행 계획 비교 분석

실행 계획 읽기 기준

먼저 볼 것은 “너무 많이 읽는가”와 “너무 틀리게 예상했는가”

실행 계획 비교 분석은 연산자 이름을 외우는 일이 아니라 문제 신호를 빠르게 분류하는 일이다. 읽는 범위가 과도한지, 옵티마이저의 예상이 실제와 크게 어긋나는지를 먼저 나누면 원인 추적이 훨씬 빨라진다.

읽는 범위 문제

조건에 맞는 소수 행만 필요해도 테이블 전체를 훑고 있으면, 접근 경로 자체가 잘못 잡힌 신호다.

보이는 신호

TABLE ACCESS FULL 이 대량 데이터 구간에서 등장

필터링 전에 너무 많은 블록을 읽고 있으므로, 비용과 버퍼 접근이 같이 커질 가능성이 높다.

먼저 의심

인덱스가 없거나, 있어도 못 타는 조건

WHERE 절 함수 적용, 타입 불일치, 선택도 낮은 조건이면 인덱스가 있어도 전체 스캔으로 기울 수 있다.

첫 점검

“필요한 범위만 읽게” 접근 경로를 줄일 수 있는가

인덱스 추가 여부와 함께 조건식 형태를 먼저 본다. 핵심은 연산자 이름보다 읽는 범위를 줄였는지다.

추정 오차 문제

옵티마이저가 적게 나올 줄 알고 계획을 골랐는데 실제로는 많이 나오면, 이후 조인 방식과 비용 판단도 같이 흔들린다.

보이는 신호

예상 1행인데 실제 100000행처럼 큰 차이

Oracle : E-Rows=1 vs A-Rows=100000 MySQL : EXPLAIN rows=1 EXPLAIN ANALYZE rows=100000

먼저 의심

통계 정보가 오래되었거나 분포를 제대로 반영하지 못함

예상치가 틀리면 NESTED LOOPS, HASH JOIN 같은 후속 선택도 잘못될 수 있다.

첫 점검

통계를 최신 상태로 맞춘 뒤 계획을 다시 본다

DBMS_STATS.GATHER 또는 ANALYZE TABLE 이후에도 차이가 크면 데이터 분포와 조건 설계를 함께 본다.

비교의 결론

FULL SCAN은 대개 읽는 범위가 과하다는 뜻이고, Rows 오차는 대개 옵티마이저 판단 근거가 틀렸다는 뜻이다. 실행 계획 비교 분석은 이 두 신호를 먼저 가르는 순간부터 빨라진다.