JSCODE Logo
JSCODE 박재성JSCODE 제이온JSCODE 시니
과외유튜브블로그후기
완강 후기 이벤트블로그 리뷰 이벤트AWS SAA 합격 후기 이벤트
회사명 : JSCODE대표 : 박재성사업자 등록번호 : 244-22-01557통신판매업 : 제 2023-인천미추홀-0381 호

서울특별시 구로구 경인로 20가길 11(오류동, 아델리아)

Copyright ⓒ 2026 JSCODE - 최상위 현업 개발자들의 프로그래밍 교육 All rights reserved.

이용약관개인정보처리방침

비전공자도 이해할 수 있는 MySQL 성능 최적화 입문/실전 (SQL 튜닝편)

MySQL 성능 최적화를 본격적으로 배우기 전에!

신입 백엔드 면접에서 자주 물어보는 ‘DB 성능 최적화’ 경험?!
DB 성능 개선할 때 ‘SQL 튜닝’을 가장 먼저 해야 하는 이유 (vs 스케일업, 레플리케이션, 샤딩, 캐싱)
성능 개선을 위한 MySQL 구조 파악 / SQL 튜닝의 핵심

인덱스(Index) 기본 개념 / 실전 활용법

인덱스(Index)란?
[실습] 인덱스 직접 설정해보기 / 성능 측정해보기
기본으로 설정되는 인덱스 (PK)
제약 조건을 추가하면 자동으로 생성되는 인덱스 (UNIQUE)
[실습] 인덱스를 무식하게 많이 걸면 어떻게 될까?
멀티 컬럼 인덱스 (Mulitple-Column Index)란?
[실습] 멀티 컬럼 인덱스 직접 설정해보기 / 작동방식 이해하기
멀티 컬럼 인덱스 생성 시 주의점
커버링 인덱스(Covering Index)란?

실행 계획(EXPLAIN)을 활용해 성능 저하 요인 찾아내기

SQL문의 ‘실행 계획’ 사용해보기 (EXPLAIN)
실행 계획에서 type 의미 분석하기 (ALL, index)
실행 계획에서 type 의미 분석하기 (const, range, ref)

SQL문 튜닝 연습하기

[실습] 한 번에 너무 많은 데이터를 조회하는 SQL문 튜닝하기
[실습] WHERE문이 사용된 SQL문 튜닝하기 - 1
[실습] WHERE문이 사용된 SQL문 튜닝하기 - 2
[실습] 인덱스를 걸었는데도 인덱스가 작동하지 않는 경우 - 1
[실습] 인덱스를 걸었는데도 인덱스가 작동하지 않는 경우 - 2
[실습] ORDER BY문이 사용된 SQL문 튜닝하기
[실습] WHERE문에 인덱스를 걸기 vs ORDER BY문에 인덱스를 걸기
[실습] HAVING문이 사용된 SQL문 튜닝하기

실전 SQL문으로 튜닝 직접 해보기

[실습] 유저 이름으로 특정 기간에 작성된 글 검색하는 SQL문 튜닝하기
[실습] 특정 부서에서 최대 연봉을 가진 사용자들 조회하는 SQL문 튜닝하기
[실습] 부서별 최대 연봉을 가진 사용자들 조회하는 SQL문 튜닝하기
[실습] 2023년 주문 데이터 조회하는 SQL문 튜닝하기
[실습] 2024년 1학기 평균 성적이 100점인 학생 조회하는 SQL문 튜닝하기
[실습] 좋아요 많은 순으로 게시글 조회하는 SQL문 튜닝하기
← 블로그 목록으로 돌아가기

멀티 컬럼 인덱스 생성 시 주의점

JSCODE 박재성
JSCODE 박재성
2026. 03. 24.
author
JSCODE 박재성
category
MySQL
createdAt
Dec 2, 2025 10:02 AM
isPublic
isPublic
series
비전공자도 이해할 수 있는 MySQL 성능 최적화 입문/실전 (SQL 튜닝편)
slug
multi-column-index-cautions
type
post
updatedAt
Mar 24, 2026 09:00

✅ 멀티 컬럼 인덱스를 만들어두면 일반 인덱스처럼 활용할 수 있다.

이전에 우리는 멀티 컬럼 인덱스를 아래와 같은 구성으로 만들었다.
notion image
부서를 기준으로 먼저 정렬이 되어 있고, 그 다음 같은 부서 내에서 이름을 기준으로 정렬되어 있다. 이런 구조로 되어 있기 때문에 부서 컬럼만 놓고 봤을 때는 부서 인덱스와 동일한 정렬 상태를 갖고 있다. 따라서 위의 멀티 컬럼 인덱스의 구조를 활용하면 부서의 인덱스를 활용하듯이 쓸 수도 있다.
 
SELECT * FROM users WHERE 부서 = '운영';
위 SQL문을 봤을 때 부서 컬럼으로 인덱스를 생성할 경우 성능이 향상되리라 짐작할 수 있다. 하지만 부서, 이름 순으로 구성된 멀티 컬럼 인덱스를 이미 만들어 뒀기 때문에, 부서 컬럼의 인덱스를 따로 또 만들 필요는 없다.
 
 

✅ 멀티 컬럼 인덱스를 일반 인덱스처럼 활용하지 못하는 경우도 있다.

위에서 부서, 이름 순으로 멀티 컬럼 인덱스를 만들어뒀기 때문에, 부서 컬럼의 인덱스를 만든 것과 같은 역할도 같이 수행한다고 했다. 하지만 이 멀티 컬럼 인덱스로는 이름 컬럼의 인덱스처럼 활용할 수는 없다.
왜인지 아래 인덱스 표를 다시 한 번 확인해보자.
notion image
정렬을 자세히 잘 살펴보면 이름 기준으로 정렬이 되어 있지는 않다. 왜냐면 같은 부서를 가진 데이터끼리만 정렬을 시켰기 때문이다. 실제로 아래 SQL문을 실행시킬 때 인덱스를 활용하지 못한다.
SELECT * FROM users WHERE 이름 = '이재현';
 
따라서 멀티 컬럼 인덱스에서 일반 인덱스처럼 활용할 수 있는 건 처음에 배치된 컬럼들뿐이다.
 
 

✅ 멀티 컬럼 인덱스를 구성할 때 ‘소분류 → 중분류 → 대분류’ 컬럼순으로 구성하기

멀티 컬럼 인덱스를 만들 때는 순서에 주의해야 한다. 왜냐하면 순서를 어떻게 정해서 인덱스를 만드느냐에 따라서 성능 차이가 나기 때문이다.
 
먼저 직관적으로 이해해보자. 대기업에서 회계 부서의 박미나를 찾아야 한다고 가정하자. 회계 부서의 모든 인원을 만나본 뒤에 박미나를 찾는게 빠를까? 아니면 박미나라는 이름을 가진 동명이인 사람들한테 직접 찾아가서 회계 부서인지를 물어보는 게 빠를까?
일반적으로 회계 부서의 인원보다 박미나라는 이름을 가진 인원이 훨씬 적기 때문에, 박미나를 먼저 찾은 뒤에 회계 부서인지를 물어보는게 빠를 것이다. 이를 일반화해서 표현하자면 ‘소분류를 먼저 탐색한 뒤, 대분류를 탐색하는 게 빠르다.’라고 할 수 있다. 컴퓨터도 이 특성이 동일하게 적용된다.
 
멀티 컬럼 인덱스에서도 배치한 컬럼의 순서대로 데이터를 탐색한다. (이름, 부서)의 순서대로 멀티 컬럼 인덱스를 구성했다면 먼저 일치하는 이름을 찾은 뒤, 일치하는 이름에서 부서를 찾는 식으로 처리한다.
 
따라서 멀티 컬럼 인덱스를 구성할 때는 데이터 중복도가 낮은(≒ 카디널리티가 높은) 컬럼이 앞쪽으로 오는 게 좋은 경우가 많다. (항상 그런 건 아니니 실행 계획과 SQL문 실행 속도를 측정해서 판단하도록 하자.)
 
 
⭐
[이것만은 꼭 기억해두자!] - 멀티 컬럼 인덱스 컬럼의 순서는 매우 중요하다. - 멀티 컬럼 인덱스에서 처음에 배치된 컬럼들은 일반 인덱스처럼 활용할 수 있다. - 멀티 컬럼 인덱스를 구성할 때 데이터 중복도가 낮은 컬럼이 앞쪽으로 오는 게 좋다.
 
📎
이 글은 비전공자도 이해할 수 있는 MySQL 성능 최적화 입문/실전 (SQL 튜닝편) 강의의 수업 자료 중 일부입니다.