MySQL EXPLAIN 읽기
2026년 8월 28일
MySQL EXPLAIN 읽기
- explain과 실행 계획의 MySQL/MariaDB 판. 쿼리 앞에
EXPLAIN만 붙이면 된다.
SQL
출력 열 중 실제로 보는 것
| 열 | 뜻 |
|---|---|
type | 접근 방식. 가장 중요 |
key | 실제로 쓴 인덱스. NULL이면 안 썼다는 뜻 |
possible_keys | 쓸 수 있었던 인덱스 후보 |
rows | 읽을 것으로 추정한 행 수 |
filtered | 그중 조건을 통과할 비율(%) |
Extra | 부가 정보. 여기 경고가 뜬다 |
type — 좋은 순서
TEXT
| type | 뜻 |
|---|---|
const | PK/유니크로 딱 1행 |
eq_ref | 조인에서 상대 행이 1건씩 |
ref | 인덱스로 여러 행 (일반적인 좋은 상태) |
range | 인덱스 범위 스캔 (BETWEEN, >, IN) |
index | 인덱스 전체를 훑음 — 풀 스캔보다 조금 나은 정도 |
ALL | 풀 스캔(Full Scan) — 경보 |
type=ALL + rows가 크면 인덱스를 추가하거나 조건을 바꿔야 한다.
Extra에서 봐야 할 문구
| 문구 | 뜻 | 판정 |
|---|---|---|
Using index | 커버링 인덱스 — 테이블을 안 읽음 | 최상 |
Using where | 읽은 뒤 조건으로 걸러냄 | 보통 |
Using index condition | 인덱스 단계에서 조건 적용(ICP) | 좋음 |
Using filesort | 별도 정렬 수행 | 정렬용 인덱스 검토 |
Using temporary | 임시 테이블 생성 | GROUP BY/DISTINCT 비용 |
Using filesort + Using temporary가 같이 뜨면 대개 GROUP BY와 ORDER BY 조합이 인덱스를 못 타는 상태다.
Mermaid스크롤로 확대 · 드래그로 이동
인덱스를 못 쓰게 만드는 대표 패턴
SQL
전부 WHERE와 조건식에서 다룬 원칙의 결과다 — 열은 그대로 두고 값 쪽을 바꾼다.
통계와 추정
rows는 추정치다. 통계가 낡으면 옵티마이저가 엉뚱한 인덱스를 고른다.
SQL
힌트는 마지막 수단이다. 데이터 분포가 바뀌면 힌트가 오히려 족쇄가 된다.
한 줄 정리
type이 ALL인지, Extra에 filesort/temporary가 있는지, rows가 실제 결과보다 훨씬 큰지 — 이 셋만 봐도 대부분 진단된다.
관련
- explain과 실행 계획
- 인덱스(Index)
- 복합 인덱스
- 풀 스캔(Full Scan)
- WHERE와 조건식
- DDL과 제약조건
- B-tree