실행 계획 확인

실행 계획(execution plan)을 확인하는 방법은 세 가지다. 실행하지 않고 예상 계획을 보는 EXPLAIN, 실제로 실행하며 재는 EXPLAIN ANALYZE, 그리고 실행 시간 측정이다. 계획을 세울 때 예상한 값과 실제로 잰 값을 구분하는 것이 출발점이다.

EXPLAIN: 예상 계획

EXPLAIN SELECT * FROM orders WHERE user_id = 42;
EXPLAIN FORMAT=JSON SELECT ...;   -- 상세·기계 판독용
EXPLAIN FORMAT=TREE SELECT ...;   -- 트리 형태(8.0.16+)

• 쿼리를 실행하지 않고 계획만 보여 준다. 핵심 칼럼은 접근 방식(type), 실제로 고른 인덱스(key), 검사할 것으로 예상한 행 수(rows), 추가 작업(Extra)이다. 읽는 법은 실행 계획 분석 문서에서 다룬다.
• FORMAT=JSON은 비용과 조건까지 자세히 보여 준다. FORMAT=TREE는 조인과 반복 구조가 트리 모양으로 한눈에 보인다.

EXPLAIN ANALYZE: 실측

EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;

쿼리를 실제로 실행하면서 예상 행 수(rows)와 실제 건수·시간·반복 횟수를 함께 보여 준다. 예상과 실측이 크게 어긋나면 세 가지를 의심한다. 계산 재료인 통계가 실제와 다른지, 서로 함께 움직이는 조건(조건 상관관계)을 따로따로 추정해 틀렸는지, 추정 모델 자체의 한계인지다. 8.4에서는 SELECT 문, 테이블 전체를 읽는 짧은 문장인 TABLE t, 그리고 여러 테이블을 한 번에 고치는 멀티테이블 UPDATE·DELETE에 사용할 수 있다. 변경 문장은 실제로 실행돼 데이터에 영향을 줄 수 있으므로 운영 환경에서 실행하지 않는다.

실행 시간 확인

• Performance 스키마(Performance Schema)로 쿼리가 거친 단계별 시간을 나눠 본다. 단계 측정은 기본으로 꺼져 있어 조사할 때만 켠다(Performance 스키마와 sys 스키마). 예전에 쓰던 SHOW PROFILES는 deprecated(폐기 예정)다.
• 슬로우 쿼리 로그(slow query log)는 정해 둔 기준 시간을 넘긴 쿼리를 기록한다. 느린 쿼리를 찾아내는 데 쓰고, 찾은 쿼리는 EXPLAIN ANALYZE로 한 번 실행해 실측하며 원인을 분석한다. 둘은 발굴과 분석의 짝이다.
• 벤치마크는 캐시 상태를 맞춰야 의미가 있다. 첫 실행은 필요한 데이터를 디스크에서 메모리 캐시인 버퍼 풀(buffer pool)로 올리느라 느리고, 두 번째 실행은 이미 올라온 데이터를 읽어 빠르다. 그래서 측정 전에 캐시를 미리 채우는 웜업(warm-up)을 해 둔다.

면접 포인트

• "EXPLAIN과 ANALYZE의 차이?" → 예상 vs 실측. 어긋나면 통계 의심.
• "FORMAT은 뭐가 있나요?" → 기본 표·JSON·TREE. 용도별 선택.
• "실행 시간 재는 법?" → ANALYZE 실측 + 프로파일 분해. 캐시 웜업 주의.