Query-Plan

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