MySQL EXPLAIN 읽는 법｜type·rows·Extra 30분 진단

느린 SQL을 발견했다고 바로 인덱스를 추가하면 쓰기 비용만 늘고 병목은 그대로 남을 수 있습니다. MySQL EXPLAIN은 쿼리가 테이블을 어떤 순서로 읽고 어떤 인덱스를 선택할지 보여주는 진단 도구입니다. 이 글에서는 결과의 모든 항목을 외우는 대신 type → key → rows·filtered → Extra 순서로 문제 구간을 좁히는 30분 점검법을 정리합니다.

진단 전에 준비할 것

먼저 느린 SELECT 한 개만 고릅니다. 애플리케이션이 실제로 사용한 SQL, 바인딩 값, 실행 시각, 반환 행 수를 함께 기록해야 재현이 가능합니다. 대상 쿼리를 아직 찾지 못했다면 MySQL 슬로우 쿼리 로그 30분 진단부터 확인하세요.

EXPLAIN
SELECT id, customer_id, total_amount
FROM orders
WHERE customer_id = 105
  AND created_at >= '2026-08-01'
ORDER BY created_at DESC
LIMIT 20;

실행 시간을 비교할 때는 같은 조건으로 3회 이상 측정하고 중앙값을 적습니다. 캐시 상태, 동시 접속, 데이터 분포가 다르면 한 번의 숫자만으로 개선 여부를 판단하기 어렵습니다.

30분 EXPLAIN 점검 순서

type부터 Extra까지 읽는 법

table은 읽을 대상이며 출력 순서는 MySQL이 테이블을 처리할 순서를 보여줍니다. type은 접근 방식입니다. 보통 const·eq_ref·ref·range는 범위를 좁혀 읽는 형태이고 ALL은 전체 스캔입니다. 그러나 행이 몇 개뿐인 작은 테이블의 ALL을 오류로 단정하면 안 됩니다. 실제로 읽는 양과 시간을 함께 봐야 합니다.

possible_keys는 후보, key는 실제 선택된 인덱스입니다. key가 NULL이면 조건에 맞는 인덱스를 찾지 못했을 가능성이 있지만, 테이블이 작아 전체 스캔이 더 싸다고 판단했을 수도 있습니다. key_len은 복합 인덱스에서 어느 범위까지 사용했는지 추정하는 단서입니다.

rows는 검사할 것으로 예상한 행 수이며 InnoDB에서는 추정값입니다. filtered는 테이블 조건을 통과할 것으로 예상한 비율입니다. 예를 들어 rows가 크고 filtered가 매우 낮다면 많은 행을 읽은 뒤 대부분 버리는 구조인지 살펴봅니다. 추정치가 실제 데이터 분포와 크게 어긋나는지는 뒤의 ANALYZE에서 확인합니다.

Extra의 Using filesort는 정렬 단계가 따로 있다는 뜻이지 항상 디스크 정렬이라는 뜻은 아닙니다. Using temporary도 임시 결과가 필요하다는 신호일 뿐, 문구 하나만 보고 장애 원인으로 확정할 수 없습니다. ORDER BY·GROUP BY 범위, 처리 행 수, 실제 시간을 함께 비교하세요.

FORMAT=TREE로 병목 위치 좁히기

EXPLAIN FORMAT=TREE
SELECT ... ;

기본 표가 테이블별 요약이라면 TREE는 스캔, 필터, 조인, 정렬의 상하 관계를 보여줍니다. 아래쪽 연산의 출력이 위쪽 연산으로 전달되므로 어디서 행 수가 커지고 어떤 단계가 반복되는지 따라가기 쉽습니다. 조인이 많은 SQL은 인덱스 이름 하나보다 전체 처리 흐름을 먼저 보는 편이 정확합니다.

EXPLAIN ANALYZE는 실제 실행에 주의

EXPLAIN ANALYZE
SELECT ... ;

EXPLAIN ANALYZE는 예상 계획만 만드는 명령이 아니라 문장을 실제로 실행합니다. 따라서 운영 서버에서 무거운 쿼리를 바로 시험하지 말고, 가능하면 운영과 비슷한 스테이징 환경에서 SELECT와 제한된 조건으로 먼저 확인하세요. 공식 문서상 다중 테이블 UPDATE·DELETE도 지원하지만 데이터 변경문에는 사용하지 않는 것을 이 글의 안전 기준으로 삼습니다.

결과에서는 estimated rows와 actual rows의 차이, actual time, loops를 봅니다. 한 단계가 빠르더라도 loops가 크게 증가하면 전체 비용이 커질 수 있습니다. 예상 10행인데 실제 10만 행이라면 조건의 선택도, 데이터 분포, 통계 상태를 우선 점검합니다.

판독 결과별 다음 행동

인덱스가 필요하다고 판단되면 즉시 운영에 추가하지 말고 MySQL 인덱스 중복·쓰기 비용 검증 절차로 이어가세요. CPU 사용률까지 동시에 상승한다면 리눅스 CPU 고사용 프로세스 추적으로 DB 프로세스와 시스템 부하를 함께 확인할 수 있습니다.

TIP: 전후 비교표를 남겨라

변경 전후에는 같은 SQL과 바인딩 값을 사용하고 실행 시간 중앙값, 실제 rows·loops, 반환 결과가 같은지 기록하세요. 인덱스를 추가했다면 INSERT·UPDATE 지연과 저장 공간도 함께 확인합니다. 속도가 개선되지 않거나 쓰기 비용이 커지면 되돌릴 기준과 명령을 변경 전에 준비해야 합니다.

마무리

EXPLAIN은 빨간 문구를 찾는 검사가 아니라 예상과 실제의 차이를 줄이는 과정입니다. 느린 SELECT를 재현하고 type·key·rows·filtered·Extra를 읽은 뒤, TREE로 흐름을 확인하고 안전한 환경에서 ANALYZE의 actual time·rows·loops를 비교하세요. 마지막으로 결과 동일성과 쓰기 영향을 확인해야 성능 개선을 설명하고 되돌릴 수 있습니다.

참고한 공식 문서

• MySQL 8.4 EXPLAIN Statement
• MySQL 8.4 EXPLAIN Output Format

검증 기준 2026년 9월 2일 MySQL 8.4 공식 문서를 다시 확인했습니다. 아래 표의 값은 독자가 자신의 환경에서 기록하는 형식이며 SJSBiz 운영 서버의 측정 결과가 아닙니다. 권한, 데이터량과 서버 부하에 따라 결과는 달라질 수 있습니다.

EXPLAIN과 EXPLAIN ANALYZE를 구분해야 하는 이유

기본 EXPLAIN은 옵티마이저가 선택한 예상 실행 계획을 보여줍니다. 반면 MySQL 8.4 공식 문서에 따르면 EXPLAIN ANALYZE는 문장을 실제로 실행하고 각 단계의 실제 시간, 반환 행 수와 반복 횟수를 출력합니다. 따라서 실행 비용을 모르는 무거운 쿼리를 운영 데이터에서 바로 분석하면 진단 자체가 부하를 만들 수 있습니다.

먼저 기본 EXPLAIN과 FORMAT=TREE로 예상 계획을 확인하고, 데이터 변경이 없는 제한된 SELECT를 스테이징이나 복제 환경에서 시험합니다. 반환 범위를 제한할 수 없거나 실행 시간이 불명확하면 운영 환경에서는 ANALYZE를 실행하지 않습니다.

변경 전후 기록표

type=ALL, Using filesort, Using temporary 같은 한 단어만으로 결론을 내리지 않습니다. 처리한 행 수, 반복 횟수, 실제 시간과 반환 결과를 함께 비교하고, 오류나 지연 증가가 나타나면 변경을 중단해 원래 계획으로 돌립니다.

문서 확인·수정 이력: 2026-09-02 — EXPLAIN ANALYZE 실행 주의, 변경 전후 기록표와 공식 근거를 추가했습니다.