MySQL 인덱스의 종류와 사용 기준, 주의사항

1. 인덱스란?

인덱스는 데이터베이스 테이블에서 원하는 데이터를 더 빠르게 찾기 위해 사용하는 자료구조야.

• 일반적으로 B-Tree 구조를 사용
• WHERE 조건이나 JOIN, ORDER BY, GROUP BY 등을 사용할 때 검색 성능을 높여줘.

 

2. MySQL 인덱스의 종류

BRIN, GIN은 MySQL에서 지원하지 않고 Partial B-Tree도 거의 사용되지 않음
👉 MySQL에서 거의 모든 경우 B-Tree 기반 인덱스 사용

3. 인덱스를 설정하는 기준 (언제 인덱스를 걸어야 할까?)

조건 설명

WHERE 절 자주 사용	예: SELECT * FROM users WHERE email = 'abc@email.com'
JOIN의 ON절	두 테이블을 자주 조인하는 컬럼에 인덱스를 설정해야 빨라져
ORDER BY / GROUP BY	정렬이나 그룹핑에 자주 쓰이는 컬럼도 인덱스 대상이야
검색 속도 느림	조회할 때 느린 쿼리에 인덱스를 추가해서 성능 개선 가능

 

4. 인덱스 설정 예시

1. 기본 인덱스

CREATE INDEX idx_user_email ON users(email);

2. 유니크 인덱스

CREATE UNIQUE INDEX idx_user_email_unique ON users(email);

3. 복합 인덱스 (두 개 이상의 컬럼)

CREATE INDEX idx_user_name_email ON users(name, email

 

5. 인덱스 주의사항

1. 인덱스가 많을수록 INSERT / UPDATE / DELETE 성능은 떨어짐

여기서 핵심 포인트: "INSERT가 있느냐 없느냐"가 아니라 → 얼마나 자주 일어나느냐가 중요

예를 들어

1. 로그 테이블 (쓰기 중심)

INSERT INTO logs (user_id, action, created_at) VALUES (1, '로그인', NOW());

• 거의 매초마다 새로운 로그가 쌓임 → 쓰기(INSERT) 엄청 많음
• SELECT는 드물게, 예: "어제 에러 로그 좀 찾아줘"
• ✅ 이럴 땐 인덱스를 최소화하는 게 좋아
  • created_at에만 인덱스 거는 식으로

1. 사용자 테이블 (읽기 중심)

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

• 가입 시 INSERT (드물게 한 번), 수정도 가끔
• 하지만 로그인 시 매번 읽힘 → SELECT 비중이 훨씬 높음
• ✅ 이럴 땐 이메일, 이름, 가입일 등 자주 조회되는 컬럼에 인덱스 거는 게 좋음

하지만 이 테이블에 인덱스 5개 있는 테이블이라면? → 테이블에 한 줄 추가 + 인덱스 5개 모두에 삽입 작업 발생, 이로 인해 대량 입력이나 배치 작업이 급격히 느려질 수 있음!

 

2. 너무 작은 테이블에는 인덱스 효과 없음

이유

• 테이블에 데이터가 10줄밖에 없는데, 인덱스를 쓴다고 성능 차이 거의 없음
• 오히려 인덱스를 거는 게 관리 비용만 생기고 성능 개선은 미미함

👉 테이블에 5줄밖에 없으면 그냥 전체 다 읽는 게 더 빠르다!

 

3. 자주 바뀌는 컬럼은 인덱스 비효율적

이유

• 인덱스는 읽기 성능 향상에 특화돼 있지만, 변경이 자주 일어나면 계속 갱신되어야 해
• 잦은 UPDATE는 인덱스를 계속 수정해야 하므로 성능 낭비

예시

UPDATE users SET login_count = login_count + 1 WHERE id = 1;

→ login_count에 인덱스가 걸려 있다면, 사용자가 로그인할 때마다 인덱스까지 수정됨

 

4. 디스크 I/O 증가 (공간 낭비)

• 인덱스도 결국 파일로 저장됨 (InnoDB에서는 별도의 B-Tree 구조로)
• 인덱스가 많으면 디스크에 더 많은 저장공간이 필요하고,
• 👉 이를 읽고 쓰기 위한 I/O 작업도 많아짐

 

끝.