실행계획(Execution Plan) 보는 방법, 느린 쿼리 잡는 핵심

실행계획(Execution Plan) 보는 방법, 느린 쿼리 잡는 핵심

SQL 성능 문제를 공부하다 보면 반드시 만나게 되는 것이 바로 실행계획(Execution Plan)입니다. 그런데 처음 보면 type, rows, key, Extra, cost 같은 정보가 한꺼번에 나와서 어디부터 봐야 할지 막막한 경우가 많습니다.

하지만 실행계획은 생각보다 어렵게 접근할 필요가 없습니다. 핵심은 단 하나입니다.

먼저 핵심부터

실행계획은 DB가 쿼리를 어떤 순서와 방식으로 처리할지 보여주는 계획표입니다.

느린 쿼리를 잡으려면 SQL 문장만 보는 것이 아니라, DB가 실제로 어떻게 읽고 조인하는지를 봐야 합니다.

즉, 실행계획은 쿼리 성능 문제의 진짜 원인을 찾는 출발점입니다.

이번 글에서는 실행계획이 무엇인지, 왜 봐야 하는지, 어디부터 읽어야 하는지, 그리고 느린 쿼리를 볼 때 어떤 항목을 먼저 체크하면 좋은지까지 초보 눈높이에서 정리해보겠습니다.

실행계획은 왜 필요할까?

같은 SQL처럼 보여도 DB가 선택한 실행 방식에 따라 성능이 크게 달라질 수 있습니다.

예를 들어 아래 쿼리를 보겠습니다.

SELECT *
FROM users
WHERE email = 'ace@example.com';

겉으로 보기엔 단순한 조회입니다. 하지만 실제로는 DB가 아래 두 방식 중 하나를 선택할 수 있습니다.

• 인덱스를 사용해서 빠르게 찾기
• 테이블 전체를 훑기

둘 다 같은 SQL이지만 성능 차이는 매우 클 수 있습니다.

즉, SQL 문장만 읽어서는 부족하고, DB가 실제로 어떤 실행 전략을 고른 것인지를 봐야 합니다. 그 정보가 바로 실행계획입니다.

한 줄로 보면

실행계획은 DB가 이 쿼리를 어떻게 실행할지 미리 보여주는 지도입니다.

728x90

실행계획은 어떻게 확인할까?

DBMS마다 형식은 조금 다르지만, 핵심 개념은 비슷합니다.

대표적으로는 EXPLAIN을 사용합니다.

EXPLAIN
SELECT *
FROM users
WHERE email = 'ace@example.com';

DBMS에 따라 출력 형식은 다르지만, 보통 아래 같은 정보를 보게 됩니다.

• 어떤 테이블을 먼저 읽는지
• 인덱스를 사용하는지
• 얼마나 많은 행을 읽을 것으로 예상하는지
• 어떤 방식으로 조인하는지
• 추가 정렬이나 임시 테이블이 필요한지

즉, 실행계획은 단순 결과가 아니라 처리 과정의 설계도입니다.

초보는 실행계획에서 무엇부터 봐야 할까?

처음부터 모든 칼럼을 외우려 하지 말고, 우선순위를 정해서 보는 편이 좋습니다.

초보가 실행계획을 볼 때는 아래 4가지를 먼저 보면 좋습니다.

1. 인덱스를 탔는가?
2. 예상 읽기 행 수(rows)가 많은가?
3. 조인 순서가 이상하지 않은가?
4. 추가 정렬/임시 테이블이 생기지 않았는가?

처음부터 모든 속성을 다 해석하려고 하면 오히려 더 어렵습니다. 성능 문제를 잡을 때는 어디서 많이 읽고, 어디서 많이 버리고, 어디서 추가 작업이 생기는지를 먼저 보는 것이 중요합니다.

처음엔 이것만

실행계획은 우선 인덱스 사용 여부, 읽는 행 수, 정렬/임시 작업만 봐도 큰 방향을 잡을 수 있습니다.

대표적으로 자주 보는 항목은?

DBMS마다 이름은 조금 달라도, 의미는 비슷한 경우가 많습니다.

MySQL 스타일 기준으로 많이 보는 항목을 예로 들면 아래와 같습니다.

항목	의미
type	어떤 방식으로 테이블을 읽는지
key	실제로 사용한 인덱스
rows	읽을 것으로 예상하는 행 수
Extra	추가 작업 정보 (Using filesort, Using temporary 등)

특히 초보 단계에서는 아래처럼 기억하면 충분합니다.

• key가 비어 있으면 인덱스를 못 탔을 가능성
• rows가 너무 크면 많은 데이터를 읽는 중일 가능성
• Extra에 Using filesort, Using temporary가 보이면 추가 비용이 있을 가능성

정말 중요한 기준

실행계획을 볼 때는 "이 쿼리가 얼마나 많이 읽고 있는가?"를 먼저 보는 습관이 중요합니다.

느린 쿼리에서 가장 먼저 의심할 것들

실행계획을 볼 때 자주 만나는 느린 쿼리 패턴입니다.

1) Full Table Scan

인덱스를 타지 못해서 테이블 전체를 읽는 경우입니다.

2) 너무 많은 rows

인덱스를 타더라도 읽는 행 수가 너무 많으면 느릴 수 있습니다.

3) 불필요한 정렬

ORDER BY 때문에 추가 정렬 비용이 크게 발생할 수 있습니다.

4) 임시 테이블 사용

그룹화나 정렬 과정에서 임시 작업이 발생할 수 있습니다.

5) 비효율적인 조인 순서

작은 테이블부터 잘 거르지 못하고 큰 데이터를 먼저 읽으면 부담이 커질 수 있습니다.

느린 쿼리 체크 포인트

느린 쿼리는 결국 너무 많이 읽거나, 불필요한 추가 작업을 많이 하거나, 둘 중 하나인 경우가 많습니다.

실행계획을 볼 때 자주 쓰는 해석 흐름

처음엔 이 순서대로 보면 훨씬 덜 헷갈립니다.

실행계획을 볼 때는 아래 순서로 접근하면 좋습니다.

1. 어떤 테이블을 먼저 읽는지 본다.
2. 인덱스를 썼는지 확인한다.
3. 예상 rows가 큰지 본다.
4. Extra에서 filesort/temporary가 있는지 본다.
5. WHERE 조건과 JOIN 조건이 인덱스를 탈 수 있는 구조인지 다시 본다.

즉, 실행계획은 단순히 “좋다/나쁘다”를 외우는 것이 아니라, DB가 어떤 선택을 했는지 따라가 보는 과정입니다.

초보용 읽는 순서

읽는 순서 → 인덱스 사용 → rows → Extra 이 4단계만 먼저 습관화해도 실행계획 해석이 훨씬 쉬워집니다.

실행계획을 보고 나서 무엇을 개선할 수 있을까?

실행계획은 문제 진단 도구이고, 그 다음에 튜닝 포인트를 찾게 됩니다.

실행계획을 보고 보통 아래 같은 개선 방향을 찾습니다.

• 적절한 인덱스 추가 또는 수정
• 불필요한 SELECT * 제거
• WHERE 조건 단순화
• 함수 사용 때문에 인덱스를 못 타는 부분 개선
• ORDER BY / GROUP BY 구조 재검토
• JOIN 순서나 JOIN 대상 축소

예를 들어 인덱스 컬럼에 함수를 걸면 DB가 인덱스를 활용하지 못할 수 있습니다.

SELECT *
FROM users
WHERE DATE(created_at) = '2026-03-24';

이런 경우는 보통 범위 조건으로 바꿔보는 것이 더 유리할 수 있습니다.

SELECT *
FROM users
WHERE created_at >= '2026-03-24 00:00:00'
  AND created_at < '2026-03-25 00:00:00';

실무 팁

실행계획은 단순 확인용이 아니라, 왜 느린지 근거를 찾고 튜닝 방향을 정하는 기준입니다.

초보가 자주 하는 오해

처음에는 실행계획을 결과표처럼만 보게 되는데, 몇 가지 오해를 같이 잡아두면 좋습니다.

1) 인덱스만 쓰면 무조건 빠르다?

아닙니다. 인덱스를 타더라도 rows가 많으면 느릴 수 있습니다.

2) rows는 실제 읽은 행 수다?

항상 그렇진 않습니다. 보통 예상치 또는 추정치입니다.

3) 실행계획만 보면 끝이다?

아닙니다. 실제 실행 시간, 데이터 분포, 인덱스 상태도 함께 봐야 합니다.

4) filesort가 보이면 무조건 틀렸다?

아닙니다. 다만 비용이 커질 수 있어 확인이 필요하다는 뜻에 가깝습니다.

초보 기준 핵심 정리

실행계획은 DB가 어떻게 읽고 조인하고 정렬하는지 보여주는 도구이고, 느린 쿼리를 잡을 때는 많이 읽는 지점과 추가 작업이 생기는 지점을 먼저 찾아야 합니다.

마무리 정리

실행계획은 DB가 쿼리를 어떤 방식으로 처리할지 보여주는 계획표입니다. 느린 쿼리를 잡을 때는 SQL 문장만 보는 것이 아니라, 인덱스를 쓰는지, 얼마나 많은 행을 읽는지, 정렬이나 임시 작업이 생기는지를 같이 봐야 합니다. 그래서 실행계획은 단순 참고 정보가 아니라 쿼리 튜닝의 출발점입니다.

실행계획 = DB의 쿼리 처리 계획표

먼저 볼 것 = 인덱스, rows, Extra

느린 쿼리 핵심 = 너무 많이 읽거나 불필요한 추가 작업이 많음

실무 시각 = 실행계획은 튜닝 방향을 찾는 지도

초보 단계에서는 우선 이렇게 기억하면 충분합니다.

실행계획은 DB가 쿼리를 실제로 어떻게 처리하는지 보여주는 지도이고, 느린 쿼리를 잡을 때 가장 먼저 열어봐야 하는 도구입니다.