MySQL 쿼리 속도 최적화 Explain 실행 계획과 인덱스로 풀 테이블 스캔 방지하는 법

Database

MySQL 쿼리 속도 최적화 Explain 실행 계획과 인덱스로 풀 테이블 스캔 방지하는 법

⏱️ 읽는 시간: 약 6분 | 📊 2,750자

개발자의 영원한 숙제, "왜 이 쿼리는 느릴까?"에 대한 심층 분석

안녕하세요. 15년 차 백엔드 엔지니어이자, 대용량 트래픽 처리를 전문으로 하는 시스템 아키텍트입니다. 개발자라면 누구나 한 번쯤 겪는 악몽이 있습니다. 평화로운 금요일 오후 5시, 퇴근 준비를 하던 찰나 모니터링 대시보드가 새빨갛게 물듭니다. 슬랙 알림은 폭주하고, 고객센터 전화기에는 불이 납니다. "접속이 안 돼요!", "주문 버튼이 안 눌러져요!" 서버 로그를 확인해보니 CPU 사용률은 98%를 찍고 있고, 데이터베이스 커넥션 풀(Connection Pool)은 이미 고갈된 상태입니다. 원인을 파고드니 범인은 단 하나, 인덱스 없이 날아간 슬로우 쿼리(Slow Query) 하나가 범인이었습니다.

저 역시 주니어 시절, 100만 건이 넘는 결제 테이블에 `WHERE` 절 조건 하나 잘못 걸었다가 전체 서비스를 30분간 마비시킨 뼈아픈 경험이 있습니다. 개발 서버에서는 데이터가 1,000건밖에 없어서 0.001초 만에 실행되던 쿼리가, 운영 환경의 500만 건 데이터와 만나자 30초가 걸리는 괴물로 돌변한 것이죠. 그때 시니어 개발자분께 들었던 "쿼리는 죄가 없다, 인덱스를 모르는 개발자가 죄인이다"라는 말은 아직도 제 가슴에 비수처럼 꽂혀 있습니다.

이 글은 단순히 "인덱스를 생성하세요"라는 뻔한 조언을 넘어섭니다. MySQL 옵티마이저가 어떻게 사고하는지, EXPLAIN(실행 계획)의 암호를 어떻게 해독하는지, 그리고 풀 테이블 스캔(Full Table Scan)이라는 최악의 시나리오를 어떻게 우아한 인덱스 스캔(Index Scan)으로 바꿀 수 있는지, 실무 레벨의 깊이 있는 노하우를 공유하려 합니다. 특히 초보자들이 자주 범하는 실수와 현업에서만 알 수 있는 고급 튜닝 기법까지 낱낱이 파헤쳐 드리겠습니다. 이제 데이터베이스 성능 최적화의 세계로 들어갈 준비가 되셨나요?

1. 풀 테이블 스캔 vs 인덱스 스캔: 성능의 갈림길

도서관 사서의 고통: 1,000만 권의 책을 바닥에서 찾기

데이터베이스의 검색 원리를 이해하는 데 있어 '도서관'만큼 완벽한 비유는 없습니다. 여러분이 도서관에서 "해리포터와 마법사의 돌"을 찾는다고 가정해봅시다. 만약 도서관의 책들이 분류 기호 없이 바닥에 무작위로 쌓여 있다면 어떨까요? 여러분은 입구에 있는 첫 번째 책부터 도서관 끝에 있는 마지막 책까지 하나하나 제목을 확인해야 합니다. 이것이 바로 풀 테이블 스캔(Full Table Scan)입니다.

데이터베이스 관점에서 풀 테이블 스캔은 디스크(Disk)에 저장된 모든 데이터 페이지를 메모리(Buffer Pool)로 퍼 올리는 I/O 집약적인 작업입니다. 디스크 I/O는 메모리 접근보다 수만 배에서 수십만 배 느립니다. 예를 들어, 1,000만 건의 데이터(약 10GB)가 있는 테이블에서 특정 ID를 찾기 위해 전체를 스캔한다면, 실제 필요한 데이터는 단 1건(수 KB)임에도 불구하고 10GB 전체를 읽어야 합니다. 이는 CPU를 낭비할 뿐만 아니라, 디스크 대역폭을 점유하여 다른 정상적인 쿼리들의 실행까지 방해하는 '블로킹(Blocking)' 현상을 유발합니다.

제가 컨설팅했던 B사의 경우, 일일 방문자 로그 테이블(약 2,000만 건)을 조회하는 어드민 페이지가 있었습니다. 특정 날짜를 조회할 때마다 15초씩 걸렸는데, 확인해보니 날짜 컬럼에 인덱스가 없었습니다. 이 쿼리 하나가 실행될 때마다 DB 서버의 I/O Wait가 80%까지 치솟았고, 결국 쇼핑몰 전체 속도가 느려지는 나비효과를 불러왔습니다.

B-Tree 인덱스: 이진 탐색의 마법

반면, 인덱스(Index)는 도서관의 '청구 기호' 또는 책 뒤편의 '색인'과 같습니다. MySQL의 InnoDB 스토리지 엔진은 기본적으로 B-Tree(Balanced Tree) 구조를 사용합니다. 핵심은 데이터가 항상 정렬된 상태로 유지된다는 점입니다. 정렬되어 있다는 것은 '이진 탐색(Binary Search)'이 가능하다는 의미이며, 이는 탐색 범위를 절반씩 줄여나갈 수 있음을 뜻합니다.

1,000만 건의 데이터가 있어도 B-Tree 인덱스를 타면, 트리의 높이(Height)만큼인 약 3~4번의 디스크 I/O만으로 원하는 데이터를 정확히 찾아낼 수 있습니다. 1,000만 번의 읽기 작업이 단 4번으로 줄어드는 것입니다. 이는 20초 걸리던 쿼리를 0.01초로 단축시키는 마법과도 같은 성능 향상을 가져옵니다.

하지만 모든 것에 인덱스를 걸 수는 없습니다. 인덱스는 테이블의 약 10~30%에 해당하는 추가 저장 공간을 차지하며, 데이터가 `INSERT`, `UPDATE`, `DELETE` 될 때마다 인덱스 트리도 재정렬(Re-balancing)해야 하므로 쓰기 성능이 저하됩니다. 즉, 조회 속도(Read)를 얻는 대신 쓰기 속도(Write)와 저장 공간을 지불하는 트레이드오프 관계임을 명심해야 합니다.

한눈에 보는 비교: 풀 테이블 스캔 vs 인덱스 스캔

💬 여러분의 경험을 들려주세요!

✨ 이 방법을 시도해보셨나요? 댓글로 공유해주세요!
📌 도움이 되셨다면 저장하고 주변에도 알려주세요.
🔔 더 많은 개발 팁을 받고 싶다면 구독해주세요!

이 글이 도움되셨나요? 공유해주세요!

🔎 관련 상품 추천

아래 링크를 통해 구매 시 운영자에게 일정 수수료가 발생할 수 있습니다.

1. **MySQL 데이터베이스 쿼리 속도가 느릴 때 Explain 실행 계획을 분석하여 인덱스(Index)를 적용하고 풀 테이블 스캔(Full Table Scan)을 방지하는 성능 최적화 방법**

'1. **MySQL 데이터베이스 쿼리 속도가 느릴 때 Explain 실행 계획을 분석하여 인덱스(Index)를 적용하고 풀 테이블 스캔(Full Table Scan)을 방지하는 성능 최적화 방법**' 관련 상품을 쿠팡에서 확인해 보세요.

상품 보러가기 →

구분	풀 테이블 스캔 (Full Table Scan)	인덱스 스캔 (Index Scan)
작동 방식	테이블의 첫 행부터 끝 행까지 모두 읽음	B-Tree를 타고 특정 위치로 바로 이동 (Random Access)
시간 복잡도	O(N) - 데이터 양에 비례하여 느려짐	O(log N) - 데이터가 늘어도 속도 저하 미미함

이 블로그 검색

DevOps & AI Info

로그 데이터 통합 관리: ELK 스택 구축 및 Kibana 시각화로 로그 지옥 탈출하기