인덱스로 쿼리 성능 올리기
인덱스로 쿼리 성능 올리기
인덱스는 MySQL이 쿼리를 빠르게 훑도록 돕는 가장 기본적인 성능 도구예요. 테이블의 모든 행을 처음부터 끝까지 읽는 대신, 인덱스가 미리 정렬해 두거나 해시로 묶어 둔 구조를 참고해 찾아야 할 행만 골라 읽죠. 그런데 "인덱스를 많이 만들수록 좋다"는 건 오히려 함정이에요. 쿼리가 쓰는 컬럼마다 전부 만들기보다, 필요한 지점에 알맞은 인덱스를 고르는 게 핵심입니다.
언제 인덱스가 필요할까요
쿼리에서 자주 사용하는 조건(WHERE, JOIN, ORDER BY 등) 컬럼이 검색 성능의 병목이라면 인덱스가 큰 도움이 돼요. 다만 MySQL 공식 문서는 "쿼리에 쓸 수 있는 모든 컬럼에 인덱스를 만드는 건 유혹적이지만, 불필요한 인덱스는 공간을 낭비하고 MySQL이 어떤 인덱스를 쓸지 판단하는 시간도 늘린다"고 짚어요. 인덱스는 데이터를 추가·수정·삭제할 때마다 함께 갱신돼야 하므로, 쓰기 작업의 비용도 더해져요.
즉 성능을 빠르게 만드는 인덱스 세트와 쓰기 비용 사이에서 균형을 찾아야 해요. 인덱스가 많다고 해서 모든 쿼리가 빨라지는 게 아니라, 쿼리 패턴에 맞는 인덱스를 정확히 배치했을 때 효과가 나옵니다.
인덱스 최적화에서 다루는 주제
Optimization and Indexes 장은 한두 페이지가 아니라 인덱스를 제대로 쓰기 위한 여러 하위 개념을 함께 다뤄요.
- How MySQL Uses Indexes — 옵티마이저가 인덱스를 언제·어떻게 사용하는지
- Primary Key Optimization — 프라이머리 키가 검색 성능에 주는 영향
- Column Indexes / Multiple-Column Indexes — 단일 컬럼·복합 컬럼 인덱스 설계
- Comparison of B-Tree and Hash Indexes — B-트리와 해시 인덱스의 동작 차이
- Invisible Indexes — 인덱스는 두고 옵티마이저가 쓰지 못하게 숨기는 기능
- Descending Indexes — 내림차순 인덱스
- Verifying Index Usage — 인덱스가 실제로 쓰이는지 확인하는 법
인덱스 동작을 직접 확인하기
사용 중인 쿼리가 어떤 인덱스를 타는지는 EXPLAIN으로 확인할 수 있어요. 인덱스를 만들기 전후로 실행 계획을 비교해 보면, 어떤 인덱스가 실제 검색을 줄여주는지가 훨씬 명확해집니다.
EXPLAIN SELECT * FROM employees WHERE last_name = 'Park';
인덱스를 만들었다면 possible_keys·key 컬럼에 그 인덱스가 실제로 선택됐는지 보이고, 행을 뒤지는 범위(rows)가 줄었는지도 함께 드러나요. 결과를 보며 인덱스 설계를 반복 수정하는 게 인덱스 최적화의 핵심입니다.
더 알아보기
- MySQL 최적화 — 옵티마이저와 서버 전반을 튜닝하는 원리
- InnoDB와 ACID 모델 — InnoDB가 데이터를 안전하게 다루는 트랜잭션 특성
- 파티셔닝 개요 — 테이블을 물리적 단위로 나눠 관리 범위를 줄이는 기법
- 복제 — 인덱스가 있는 테이블을 여러 서버로 동기화하는 방법