EXPLAIN은 옵티마이저가 선택한 실행 계획, 즉 각 테이블에 어떻게 접근할지를 쿼리를 실행하지 않고 보여줍니다. 인덱스가 사용되는지, 검사하는 행이 적은지 확인하기 위해 읽습니다.
const / eq_ref / ref(인덱스 조회, 좋음) → range → index(전체 인덱스 스캔) → ALL(풀 테이블 스캔, 위험 신호).NULL = 없음).Using index(커버링, 훌륭함), Using filesort / Using temporary(메모리나 디스크에서의 정렬/그룹화 — 종종 최적화 가능).EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- +------+------+------+---------+--------+----------------+
-- | type | key | rows | Extra |
-- | ALL | NULL | 900k | Using where; Using filesort | <- scans everything, sorts
-- +------+------+------+---------+--------+----------------+
-- Add an index that covers the filter AND the sort order:
CREATE INDEX idx_cust_created ON orders (customer_id, created_at);
EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- | type | key | rows | Extra |
-- | ref | idx_cust_created | 30 | Using where | <- seeks 30 rows, no filesort
이 인덱스는 90만 행에 대한 ALL 스캔을 30행에 대한 ref 탐색으로 바꿨고, created_at이 두 번째 컬럼이므로 행이 이미 정렬된 상태로 나옵니다 — filesort가 사라지죠.
EXPLAIN ANALYZE(MySQL 8)를 사용하면 실제 소요 시간과 행 수도 볼 수 있어, 추정치가 틀린 경우를 잡아낼 수 있습니다.
EXPLAIN은 추측을 증거로 대체하는 방법입니다. type: ALL, 거대한 rows, Using filesort를 발견하면 어디에 인덱스가 빠졌는지 정확히 알 수 있습니다 — "페이지가 느리다"에서 표적화된 수정에 이르는 가장 빠른 길이죠.
주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기