Apr 3, 2026

MySQL index design 가이드: 인덱스는 어떻게 설계해야 할까

MySQL 성능을 다룰 때 인덱스는 거의 항상 핵심으로 등장합니다. 하지만 입문 단계에서는 “인덱스를 만들면 빨라진다” 정도만 기억하고, 어떤 기준으로 설계해야 하는지는 헷갈리기 쉽습니다.

이 글에서는 아래 내용을 정리합니다.

인덱스가 왜 중요한지
어떤 컬럼에 인덱스를 고려해야 하는지
WHERE, ORDER BY, JOIN 기준으로 어떻게 생각해야 하는지
왜 인덱스를 무조건 많이 만들면 안 되는지

핵심은 인덱스는 단순히 컬럼에 붙이는 옵션이 아니라, 실제 쿼리 패턴에 맞춰 접근 경로를 설계하는 일이라는 점입니다.

인덱스는 왜 중요한가

인덱스가 없으면 MySQL은 원하는 데이터를 찾기 위해 훨씬 많은 row를 읽어야 할 수 있습니다. 반대로 적절한 인덱스가 있으면 필요한 범위만 빠르게 좁혀서 읽을 수 있습니다.

즉, 인덱스의 역할은 단순히 “검색 속도 향상”보다 “읽는 양을 줄이는 것”에 더 가깝습니다.

어떤 컬럼에 인덱스를 고려할까

보통 아래 위치에 자주 등장하는 컬럼부터 봅니다.

WHERE 조건
JOIN 조건
ORDER BY 조건
GROUP BY 조건

다만 “자주 등장한다”와 “좋은 인덱스 후보다”는 조금 다를 수 있습니다. 데이터 분포와 쿼리 패턴도 같이 봐야 합니다.

WHERE 기준으로 볼 때

필터링에 자주 쓰이는 컬럼은 대표적인 인덱스 후보입니다. 하지만 선택도가 너무 낮은 컬럼은 기대만큼 도움이 안 될 수 있습니다.

예를 들어:

거의 모두가 status = active

같은 경우는 필터 효과가 약할 수 있습니다.

즉, 인덱스는 “자주 쓰이는가”뿐 아니라 “얼마나 잘 좁혀주는가”도 중요합니다.

ORDER BY까지 같이 생각해야 하는 이유

많은 초보자가 WHERE만 보고 인덱스를 잡지만, 실제 쿼리는 정렬 비용도 큽니다. 조건 필터와 정렬이 자주 함께 나오면 인덱스 순서가 매우 중요해집니다.

예를 들어:

WHERE user_id = ?
ORDER BY created_at DESC

같은 패턴이 자주 나온다면, 단일 인덱스 하나보다 조합 인덱스가 더 유리할 수 있습니다.

JOIN에서는 무엇을 볼까

조인 키는 거의 항상 중요한 후보입니다. 조인 대상 row를 빠르게 찾지 못하면 읽는 양이 크게 늘어납니다.

특히:

부모-자식 관계
외래 키 기반 조회
자주 붙는 테이블 조합

에서는 조인 컬럼 인덱스를 빠뜨리면 성능이 급격히 나빠질 수 있습니다.

복합 인덱스는 어떻게 생각할까

복합 인덱스는 여러 컬럼을 함께 묶은 인덱스입니다. 여기서 중요한 것은 컬럼의 순서입니다.

보통은:

자주 쓰이는 필터 조건
그 다음 정렬이나 추가 조건

순으로 고민하는 경우가 많습니다.

하지만 정답은 항상 고정이 아니라, 실제 쿼리 패턴과 데이터 특성에 따라 달라집니다.

인덱스를 너무 많이 만들면 왜 안 좋을까

인덱스는 읽기에는 도움이 되지만, 쓰기에는 비용이 듭니다.

즉:

INSERT
UPDATE
DELETE

마다 인덱스도 함께 관리해야 해서 쓰기 성능과 저장 공간 비용이 늘어납니다.

그래서 인덱스는 많을수록 좋다기보다, 필요한 만큼 정확하게 있어야 좋습니다.

자주 하는 오해

1. 자주 쓰는 컬럼이면 무조건 인덱스를 만든다

선택도와 쿼리 패턴을 안 보면 효과가 거의 없을 수 있습니다.

2. 인덱스는 많을수록 안전하다

읽기에는 좋아 보여도 쓰기와 운영 복잡도는 커집니다.

3. 단일 인덱스 여러 개면 복합 인덱스와 같다

실제 실행 방식은 전혀 다를 수 있습니다.

FAQ

Q. 인덱스 설계는 어디서 시작하면 좋을까

느린 쿼리와 자주 실행되는 쿼리부터 보는 것이 가장 실용적입니다.

Q. 복합 인덱스 순서는 어떻게 정하나

WHERE, JOIN, ORDER BY 패턴이 실제로 어떻게 함께 나오는지 먼저 봐야 합니다.

Q. 인덱스가 잘 먹는지는 어떻게 확인하나

EXPLAIN으로 실행 계획과 읽는 row 수를 확인하는 것이 좋습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.