📘 Index?

인덱스(Index)라는 말을 처음 들었을 때 그냥 배열에서 쓰던 그 인덱스인 줄 알았다.

0부터 시작하는 그거..그냥 순서 아닌가라고 생각했다.

근데 DB에서 말하는 인덱스는 이거와는 완전히 다른 개념이다.
순서라기 보다는 데이터를 빠르게 찾기 위한 장치에 가깝다.

예를들어 학생 1만 명이 있는 리스트에서 “임승제” 한 명을 찾는다고 하자.
인덱스가 없다면 처음부터 끝까지 하나씩 다 확인해야 하지만, 인덱스가 있다면 바로 위치를 찾아갈 수 있다. 이 차이가 쌓이면 속도 차이가 말도 안 되게 벌어진다.

데이터베이스에서 인덱스는 단순히 있으면 좋은 기능이 아니라 성능을 좌우하는 핵심 요소다.

Index

데이터를 빠르게 찾기 위한 별도의 자료구조

여기서 중요한 건 원본 데이터를 바꾸는 게 아니라, 따로 구조를 만들어 관리한다는 점이다.

인덱스가 없다면 DB는 데이터를 어떻게 찾을까?

예를 들어 users 테이블에 데이터가 1만 개 있다고 해보자.

여기서 name이 “임승제”인 데이터를 찾으려면 DB는 1번부터 10000번까지 하나씩 다 확인해야 한다.

이걸 Full Scan이라고 한다. 데이터가 많아질수록 이 방식은 점점 느려진다.

그럼 인덱스가 있으면 어떻게 될까?

name에 인덱스를 걸면 DB는 name 기준으로 정렬된 “목차”를 따로 만들어둔다.

이걸 이해하기 쉽게 비유해보면 도서관을 생각해보면 된다.

책이 1만 권 있는데 인덱스가 없다면? 처음부터 한 권씩 다 뒤져야 한다.
근데 도서관에는 보통 “책 제목별로 정리된 색인표”가 있다.
그래서 “해리포터”를 찾고 싶으면 색인표에서 위치 확인 → 바로 해당 책장으로 이동한다.

이게 바로 인덱스다.

데이터를 직접 찾는 게 아니라 데이터가 어디 있는지를 먼저 찾는 구조다.
그래서 인덱스가 있으면 Full Scan을 하지 않고 바로 해당 위치로 접근할 수 있어서 속도가 훨씬 빨라진다.

그럼 실제로는 어떻게 만드는 걸까?

CREATE INDEX idx_user_name ON users(name); // name 컬럼 기준 인덱스 생성

DROP INDEX idx_user_name; // 인덱스 삭제

이렇게 간단하게 인덱스를 만들 수 있다.

이렇게만 보면 그냥 무조건 인덱스를 쓰는게 좋아보인다.
하지만 인덱스는 마법이 아니다.

무조건 빠르게 만들어주는 게 아니라 조건에 따라 성능을 바꾸는 도구다.

왜냐하면 인덱스는 조회를 빠르게 해주는 대신 쓰기 작업에는 부담을 주기 때문이다.

예를 들어 데이터를 추가하거나 수정할 때
INSERT → 인덱스에도 추가
DELETE → 인덱스에서도 제거
UPDATE → 기존 인덱스 제거 + 다시 추가

이 과정이 계속 발생한다.

조회는 빨라지지만 쓰기 성능은 오히려 느려질 수 있는거다..

그리고 인덱스 자체도 따로 저장되기 때문에 추가적인 저장 공간 또한 필요하다.

그래서 인덱스는 많이 쓰는 게 아니라 잘 써야 하는 것이다.

---

Index 사용하는 경우

그럼 인덱스는 언제 사용하는 게 좋을까?

1️⃣ 데이터의 양이 많은 경우

데이터가 몇 개 없을 때는 Full Scan으로도 충분히 빠르다.
하지만 데이터가 수천, 수만, 수백만 단위로 늘어나면 전체를 탐색하는 비용이 급격히 증가한다.

이럴 때 인덱스를 사용하면 검색 범위를 줄일 수 있기 때문에 성능이 크게 개선된다.

2️⃣ 특정 컬럼으로 자주 조회하는 경우

WHERE 조건에 자주 등장하는 컬럼이라면 인덱스를 사용하는 것이 효과적이다.

예를 들어 id, email, name 같이 특정 값을 기준으로 조회하는 경우가 많다면 해당 컬럼에 인덱스를 거는 것이 좋다.

3️⃣ 정렬이 자주 발생하는 경우

ORDER BY를 자주 사용하는 컬럼이라면 인덱스를 통해 정렬된 결과를 빠르게 가져올 수 있다.

4️⃣ JOIN 연산이 많은 경우

테이블을 연결할 때 인덱스가 없다면 모든 데이터를 비교해야 한다.
하지만 인덱스가 있다면 연결할 데이터를 빠르게 찾을 수 있어서 성능 차이가 크게 난다.

5️⃣ 중복을 막고 싶은 경우

UNIQUE 인덱스를 사용하면 중복 데이터를 아예 저장하지 못하게 만들 수 있다.
성능뿐만 아니라 데이터의 무결성도 함께 보장할 수 있는거다.


인덱스는 단순히 빠르게 해주는 기능이 아니라 필요한 곳에만 정확하게 사용하는 최적화 도구다.

---

Index 종류

인덱스에도 크게 두 가지 형태가 있다.

1️⃣ 클러스터형 인덱스 (Clustered Index)

데이터 자체가 정렬된 상태로 저장되는 인덱스

쉽게 말하면 데이터를 인덱스 기준으로 그대로 정렬해서 저장하는 방식이다. 그래서 테이블당 하나만 존재할 수 있다.
왜냐하면 데이터는 한 번에 한 가지 기준으로만 정렬될 수 있기 때문이다.

이걸 비유하면 영어사전이랑 비슷하다.

영어사전은 단어 자체가 알파벳 순서로 정렬되어 있어서 따로 찾는 과정 없이 바로 위치를 찾아갈 수 있다.

즉, 데이터 자체가 이미 인덱스 역할을 하고 있는 구조다.

2️⃣ 보조 인덱스 (Secondary Index)

실제 데이터와는 별도로 만들어지는 인덱스

이건 데이터 자체를 건드리는 게 아니라 위치만 따로 정리해둔 구조다. 그래서 하나의 테이블에 여러 개를 만들 수 있다.

이건 책 뒤에 있는 목차랑 비슷하다.
책 내용은 그대로 있는데 목차를 통해 특정 내용을 빠르게 찾는 것처럼 보조 인덱스도 데이터 위치를 먼저 찾고 → 실제 데이터를 접근한다.

---

Index 동작원리

그럼 인덱스는 내부적으로 어떻게 동작할까?

대부분의 데이터베이스는 인덱스를 구현할 때 B-Tree라는 구조를 사용한다.
이름만 보면 뭔가 어려워 보이는데 생각보다 개념은 단순하다.

데이터를 정렬된 상태로 저장해두고 필요한 범위만 빠르게 찾아가는 구조다.

구조를 보면
루트 노드 → 중간 노드 → 리프 노드
이렇게 계층적으로 이루어져 있다. 검색할 때는 루트부터 시작해서 조건에 맞는 방향으로 계속 내려간다.

즉 데이터를 처음부터 끝까지 보는 게 아니라
“이 범위는 아니네 → 다음 범위”
이렇게 탐색 범위를 계속 줄여가는 방식이다. 그래서 데이터가 많아져도 검색 속도가 크게 느려지지 않는다.

이게 바로 인덱스가 빠른 이유다.

그리고 여기서 중요한 특징 하나 B-Tree는 “균형 트리”다.
데이터가 추가되더라도 자동으로 노드를 나누고 구조를 정리하면서 항상 비슷한 깊이를 유지한다.
그래서 한쪽으로 쏠리는 일이 없고 항상 일정한 탐색 성능을 유지할 수 있다.

근데 실제 DB에서는 B-Tree보다 B+Tree 구조를 더 많이 사용한다.

차이는 크게 어렵지 않다.
B-Tree는 중간 노드에도 데이터가 있지만, B+Tree는 실제 데이터가 리프 노드에만 존재한다. 그리고 리프 노드끼리 연결되어 있다.

이게 왜 중요하냐면
범위 검색 (예: 가격 10,000 이상) 정렬 (ORDER BY)
이런 작업을 할 때 엄청 빠르게 처리할 수 있기 때문이다.

그래서 대부분의 DB는 B+Tree 기반 인덱스를 사용한다.

그럼 B-Tree 말고 다른 인덱스도 있을까?
여기까지 보면 인덱스가 하나처럼 보이는데, 사실 종류가 꽤 많다.

가장 기본은 B-Tree 인덱스다.
우리가 일반적으로 사용하는 인덱스 대부분이 이 구조다.
WHERE 조건이나 범위 검색 같은 일반적인 상황에서는 거의 이걸로 해결된다.

Unique Index는 중복을 허용하지 않는 인덱스다.
Primary Key나 이메일처럼 값이 유일해야 하는 경우에 사용된다.
단순히 빠르게 찾는 것뿐만 아니라, 데이터 자체를 제한하는 역할도 한다.

Composite Index는 여러 컬럼을 묶어서 만든 인덱스다.
예를 들어 이름 + 나이 이렇게 두 개를 함께 인덱스로 만들 수 있다.
처음 보면 그냥 “두 개 합친 거네?” 싶은데 막상 써보면 그렇게 단순하지가 않다.
순서 하나 때문에 결과가 완전히 달라지기도 해서 이건 나중에 따로 정리해봐야겠다 싶었다.

Hash Index는 해시 값을 기반으로 데이터를 찾는다.
그래서 정확히 같은 값을 찾는 데는 매우 빠르다.
하지만 범위 검색은 불가능하다..
그래서 일반적인 DB보다는 NoSQL이나 특정 상황에서만 사용된다.

Bitmap Index는 값의 종류가 적고, 중복이 많은 컬럼에서 사용된다.
예를 들어 성별, 상태값 같은 데이터다.
일반 서비스보다는 데이터 분석용(DB, DW)에서 많이 사용된다.

Full-Text Index는 텍스트 검색을 위한 인덱스다.
게시판 검색이나 검색엔진 같은 기능에서 사용된다.
LIKE 검색보다 훨씬 빠르고 단어 단위 검색이 가능하다.

---

인덱스는 단순히 빠르게 해주는 기능이 아니라 상황에 따라 선택하는 도구다.
실무에서는 대부분 B-Tree 기반 인덱스와 복합 인덱스를 중심으로 사용한다.

결국 중요한 건 인덱스를 많이 아는 게 아니라, 어디에 어떻게 사용하는지다.

메뉴판이 잘 정리되어 있으면 원하는 메뉴를 바로 고를 수 있듯이, 데이터도 인덱스가 잘 설계되어 있으면 전체를 뒤지지 않고 바로 원하는 값을 찾을 수 있다.