같은 질문으로 읽기
DBMS마다 명령은 달라도, 실행 계획은 항상 예상 계획 확인과 실행 후 검증으로 나눠서 본다.
1. 계획만 먼저 본다 옵티마이저가 어떤 접근 경로와 조인 순서를 선택했는지 빠르게 확인한다.
2. 실행 후 실제 통계를 본다 예상 Rows, 실제 시간, 버퍼 사용량 차이로 통계 불일치와 병목을 검증한다.
DBMS
계획만 확인
실행 후 검증
실무에서 특히 보는 점
Oracle 예상 계획과 실제 행수 차이를 추적하기 좋다.
계획만 보기
EXPLAIN PLAN
DBMS_XPLAN.DISPLAY
실행 후 검증
AUTOTRACE
DBMS_XPLAN.DISPLAY_CURSOR
Rows 예측과 실제 실행 행수가 크게 다르면 통계 정보나 데이터 분포를 의심한다.
MySQL 계획 표현 형식을 바꿔 구조를 읽기 쉽다.
계획만 보기
EXPLAIN
EXPLAIN FORMAT=JSON
EXPLAIN FORMAT=TREE
실행 후 검증
EXPLAIN ANALYZE
TREE/JSON은 조인 순서와 접근 방식을 읽기 좋고, ANALYZE는 실제 실행 시간까지 확인한다.
PostgreSQL 시간과 버퍼 사용량을 함께 읽기 편하다.
계획만 보기
EXPLAIN
실행 후 검증
EXPLAIN ANALYZE
EXPLAIN (ANALYZE, BUFFERS)
실행 시간만이 아니라 버퍼 접근량까지 보면 CPU 병목인지 I/O 병목인지 판단이 빨라진다.
SQL Server 추정 계획과 실제 계획을 세션/도구에서 함께 확인한다.
계획만 보기
SET SHOWPLAN_ALL ON
실행 후 검증
SET STATISTICS PROFILE ON
Actual Execution Plan
추정 계획만 보면 누락되는 실제 실행 경로를 SSMS 실제 계획과 함께 비교해 본다.
핵심
외울 것은 명령 이름의 목록이 아니라 예상 계획을 본 뒤 실제 실행 통계로 검증한다는 공통 절차다. 이 축만 고정하면 어떤 DBMS에서도 실행 계획을 같은 방식으로 해석할 수 있다.