개요

EXPLAIN은 SELECT가 어떤 경로로 데이터를 읽는지 드러내는 도구 병목 파악과 인덱스 전략 점검에 사용

핵심 개념

  • select_type
    • SIMPLE 단순 SELECT, 서브쿼리나 UNION 없음
    • PRIMARY 가장 바깥쪽 SELECT
    • SUBQUERY 서브쿼리
    • DERIVED FROM 절의 서브쿼리
    • UNION UNION의 두 번째 이후 SELECT
  • type 실행 품질 지표, 위에서 아래로 유리
    • system 테이블에 단 하나의 행
    • const PRIMARY KEY 또는 UNIQUE 인덱스 단건 조회
    • eq_ref 조인에서 PRIMARY KEY 또는 UNIQUE로 정확히 1행 매칭
    • ref 인덱스를 사용한 동등 조건 검색
    • range 인덱스를 사용한 범위 검색
    • index 인덱스 전체 스캔
    • ALL 테이블 전체 스캔, 최악
  • possible_keys 사용 가능한 인덱스 목록, NULL이면 후보 없음
  • key 실제 사용된 인덱스, NULL이면 인덱스 미사용
  • rows 옵티마이저가 읽을 것으로 추정한 행 수, 낮을수록 유리
  • filtered 조건 후 남는 행 비율 추정치, 높을수록 유리
  • Extra 추가 단서
    • Using index 커버링 인덱스 사용, 유리
    • Using where WHERE 조건으로 필터링 수행
    • Using filesort 추가 정렬 필요, 비용 큼
    • Using temporary 임시 테이블 사용, 비용 큼

해석 기준

  • type이 const, ref, range 범주에 위치
  • key가 NULL이 아니고 적절한 인덱스 선택
  • rows 추정치가 작고 filtered 비율이 높음
  • Extra에 Using filesort, Using temporary 부재

예시와 해석

type: ALL
possible_keys: NULL
rows: 3527425
Extra: Using where; Using filesort
  • 테이블 전체 스캔으로 많은 행을 읽게 됨
  • 인덱스 후보와 실제 사용 인덱스가 없음
  • WHERE로 필터링하고 추가 정렬까지 수행하여 비용 상승
  • 현재 계획은 인덱스 설계와 조건식 재검토 필요

주의와 팁

  • rows와 filtered는 통계 기반 추정치라 실제와 오차 가능
  • filtered는 대략 rows × filtered%로 남는 행 규모 가늠에 사용
  • Using filesort가 항상 나쁜 것은 아님, 결과 집합이 매우 작으면 영향 미미할 수 있음
  • 인덱스 생성 시 조건 컬럼의 선택도와 정렬·조인 키 우선 고려
  • 커버링 인덱스 구성 시 Extra의 Using index로 확인 가능

마무리

EXPLAIN은 증상 관찰 도구, 원인은 스키마 설계와 조건식, 인덱스 전략에서 찾기 위 지표를 기준으로 스캔 범위를 줄이고 불필요한 정렬과 임시 테이블을 제거하는 방향으로 개선 시도 권장

참고자료