인덱스? 그냥 있으면 빨라지는 거 아님?

Zain·2025년 3월 3일

Index란?

데이터베이스에서 Index(인덱스) 는 검색 속도를 높이기 위해 특정 컬럼에 대해 생성하는 데이터 구조임.
도서관에서 책 찾을 때 색인 활용하는 거랑 같음.
테이블에서 원하는 데이터를 빠르게 찾으려고 인덱스를 만들면, DBMS는 전체 데이터를 순차적으로 검색하는 대신 인덱스를 이용해 빠르게 접근할 수 있음.

✅ Index의 역할

검색 속도 향상
- WHERE, JOIN, ORDER BY 등에 사용되는 컬럼에 인덱스를 적용하면 검색 속도가 빨라짐.
B-Tree 또는 Hash 구조를 사용하여 데이터를 효율적으로 찾음.
정렬 성능 향상
- ORDER BY 또는 GROUP BY 시 인덱스가 적용된 컬럼이 있으면 추가 정렬 작업이 줄어들어 성능 개선.
유일성(Unique) 보장
- UNIQUE INDEX를 사용하면 중복 데이터를 방지할 수 있음.

✅ Index를 사용해야 하는 경우

자주 검색하는 컬럼 (WHERE 조건에 자주 사용되는 경우)

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

→ email 컬럼에 인덱스를 걸면 빠르게 검색 가능.

JOIN 연산에 사용되는 컬럼

SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id;

→ customer_id 컬럼에 인덱스를 걸면 JOIN 성능이 향상됨.
-정렬 (ORDER BY) 및 그룹화 (GROUP BY) 컬럼

SELECT * FROM users ORDER BY created_at DESC;

→ created_at에 인덱스가 있으면 정렬 속도 개선.
-유니크한 값이 많은 컬럼
-인덱스는 분포도가 높은(중복 값이 적은) 컬럼에서 효과적임.
-예: email, user_id 같은 유니크한 값이 많은 컬럼.

❌ Index를 사용하지 말아야 하는 경우

자주 변경되는 컬럼 (UPDATE, DELETE가 빈번한 경우)
- ex) 회원의 last_login_time 같은 자주 변경되는 컬럼은 인덱스 업데이트 부담이 커짐.
중복 값이 너무 많은 컬럼
- ex) 성별(gender) 컬럼처럼 M, F 두 개의 값만 존재하는 경우 인덱스 효율이 떨어짐.
작은 테이블(ROW 수가 적은 테이블)
- 데이터가 몇 백 개 이하라면 인덱스를 사용하지 않아도 충분히 빠름.

✅ Index 종류

Primary Index (기본 키 인덱스)
- PRIMARY KEY 컬럼에 자동으로 생성됨.
- 클러스터형 인덱스(Clustered Index)로 작동하여 테이블의 물리적 저장 순서를 결정.
Unique Index (유니크 인덱스)
-UNIQUE 제약 조건을 가지며 중복을 방지.
```
CREATE UNIQUE INDEX idx_users_email ON users(email);
```
Composite Index (복합 인덱스)
- 여러 개의 컬럼을 조합한 인덱스.
```
CREATE INDEX idx_users_name_dob ON users(name, date_of_birth);
```
- name 또는 name + date_of_birth 검색 시 사용 가능하지만, date_of_birth 단독 검색에는 사용 불가능.
Full-Text Index (전문 검색 인덱스)
- 긴 텍스트 검색에 사용 (MATCH AGAINST 지원).
```
CREATE FULLTEXT INDEX idx_posts_content ON posts(content);
```
Covering Index (커버링 인덱스)
- 인덱스에 포함된 모든 컬럼을 SELECT할 경우 테이블 조회 없이 인덱스만으로 결과를 반환.

🎯 결론

WHERE / JOIN / ORDER BY / GROUP BY 에 자주 사용되는 컬럼에 인덱스를 적용하면 성능이 향상됨.
INSERT / UPDATE / DELETE 가 자주 발생하는 컬럼에는 신중하게 사용해야 함.
중복 값이 많거나 테이블 크기가 작은 경우, 인덱스 사용이 비효율적일 수 있음.
EXPLAIN 을 활용하여 성능을 분석하고, 불필요한 인덱스는 제거하는 것이 중요.

Back to Table란?

WHERE 절에서 인덱스를 사용하여 특정 행을 찾았지만, SELECT 절에서 인덱스에 없는 컬럼을 조회하려고 할 때 발생하는 추가적인 테이블 접근을 의미합니다.
즉, 인덱스에 포함되지 않은 컬럼을 조회하기 위해 다시 테이블을 조회해야 하는 것입니다.

Back to Table 발생 예제

CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,  -- Primary Key (id)
    name VARCHAR(100),
    email VARCHAR(255),
    age INT
);

id가 PRIMARY KEY이므로 자동으로 클러스터드 인덱스가 생성됨.

Back to Table이 발생하는 경우

SELECT id, name FROM users WHERE id = 1;

id는 PRIMARY KEY이므로 인덱스를 사용하여 빠르게 찾음
하지만 name은 인덱스에 없기 때문에 추가적으로 테이블(users)을 조회해야 함
즉, Back to Table 발생 (테이블 조회 추가 발생)
👉 Extra: Using where

✅ Back to Table 방지하는 방법 → Covering Index 사용

만약 id와 name을 자주 함께 조회한다면, 인덱스에 name을 포함하면 성능이 향상됨 🚀

CREATE INDEX idx_users_id_name ON users(id, name);

이제 다음 쿼리는 테이블 조회 없이 인덱스만으로 해결 가능:

SELECT id, name FROM users WHERE id = 1;

👉 Extra: Using index (추가적인 테이블 조회 없음)
✅ 인덱스에서 모든 데이터를 가져올 수 있어 성능이 향상됨!

Back to Table 결론

✅ 자주 조회하는 컬럼들은 Covering Index를 맺는 것이 성능 최적화에 유리함.
✅ Back to Table 은 인덱스로 찾은 후, 추가적인 컬럼을 조회하기 위해 다시 테이블을 조회하는 것.
✅ Covering Index를 활용하면 테이블 조회 없이 인덱스에서만 데이터를 가져와 성능을 향상시킬 수 있음 🚀 🚀