인덱스

데이터베이스에서 검색 속도를 향상시키기 위한 자료구조
책의 목차처럼, 원하는 데이터를 빠르게 찾을 수 있도록 도와줌
특정 컬럼에 인덱스를 생성하면 해당 컬럼을 검색할 때 속도가 크게 향상됨

클러스터형 인덱스 vs 비클러스터형 인덱스

기본적으로 모든 인덱스는 이 두 개념 중 하나에 속함
데이터 저장 방식과 검색 방식에 차이가 있음

클러스터형 인덱스 (Clustered Index)

데이터 자체가 인덱스 순서대로 저장됨
따라서 검색이 빠르지만, 데이터의 삽입/삭제 시 재정렬이 필요할 수 있음
PK에 자동으로 생성되며, 테이블당 하나만 존재 가능

비클러스터형 인덱스 (Non-Clustered Index)

PK 이외의 컬럼에서 검색 속도를 높이기 위해 사용됨
인덱스와 실제 데이터가 따로 저장되므로, 조회 시 한 단계 더 검색해야 함
인덱스 전용 테이블이 별도로 생성
한 테이블에 여러 개의 비클러스터형 인덱스를 생성할 수 있음
보조 인덱스(Secondary Index)라고도 불림

인덱스의 자료구조

B-Tree구조

모든 노드에 데이터가 저장됨
전체 데이터를 여러 블록(노드)로 분할해 저장
검색, 삽입, 삭제 속도 O(log N) -> 빠르게 탐색 가능

B+Tree

B-Tree의 단점을 보완한 자료구조
리프노드가 연결 리스트 형태로 구성되고, 리프 노드에만 데이터를 저장하여 범위 검색이 빠름
루트 노드, 중간 노드는 키 값만 저장

클러스터형 인덱스의 자료구조(B+Tree를 사용하는 경우)

클러스터형인덱스는 데이터 자체가 리프 노드에 저장됨
리프 노드에 실제 데이터가 저장되며, 키 값(id) 순서대로 정렬됨
즉, 인덱스를 따라가면서 데이터를 찾으면 추가적인 참조 없이 바로 데이터를 읽을 수 있음

비클러스터형 인덱스의 자료구조(B+Tree를 사용하는 경우)

비클러스터형 인덱스는 인덱스와 실제 데이터가 별로도 저장됨
리프 노드에는 실제 데이터가 아닌 PK를 참조하는 값이 저장됨
검색을 수행하면 먼저 인덱스를 검색하고, 다시 PK를 참조하여 실제 데이터를 가져와야 함

인덱스 생성 방법

클러스터형 인덱스 생성

테이블의 실제 데이터 저장 순서를 결정하는 인덱스
PK를 설정하면 자동으로 생성됨
테이블마다 하나만 생성 가능함
인덱스를 따라가면 바로 데이터에 접근할 수 있음(추가 탐색 불필요)

기본 인덱스 생성(비클러스터형 인덱스)

하나 또는 여러 컬럼에 대해 인덱스를 생성하는 방법
CREATE INDEX 구문으로 생성됨
비클러스터형 인덱스가 생성됨(이미 클러스터형 인덱스가 존재하므로)
인덱스를 따라가서 다시 테이블을 참조해야 데이터에 접근 가능함

고유 인덱스(Unique Index) 생성

중복되지 않는 값을 저장해야 하는 컬럼에 사용
UNIQUE 제약 조건이 포함된 인덱스를 생성하면 중복값 입력이 불가능함
중복 방지를 위한 제약 조건이 주요 목적이며, 인덱스 자체는 보통 비클러스터형 인덱스로 생성됨
단, PK로 지정되는 경우에는 클러스터형 인덱스로 생성됨

복합 인덱스 (Composite Index)

여러 개의 컬럼을 하나의 인덱스로 묶어서 생성하는 인덱스
하나의 인덱스로 여러 컬럼을 동시에 검색할 때 성능을 최적화함

사용 이유

• WHERE 조건에서 여러 개의 컬럼을 함께 검색하는 경우 속도를 최적화하기 위해
• 데이터베이스가 여러 개의 컬럼을 하나의 트리 구조에서 관리하도록 하여, 검색 효율을 높일 수 있음
• 하나의 인덱스를 사용하여여러 조건을 동시에 만족하는 데이터를 빠르게 찾을 수 있음

주의할 점
CREATE INDEX idx(col1, col2, col3)처럼 복합 인덱스를 만들면 인덱스를 활용하려면 col1부터 순서대로 WHERE 절에 포함되어야 함
예를 들어, col2, col3만 조건에서 사용하면 인덱스를 사용할 수 없음
즉, 인덱스는 지정한 컬럼 순서대로 조건이 걸려 있어야 성능이 최적화됨

인덱스와 성능

인덱스는 데이터베이스에서 검색 성능을 향상시키지만, 잘못 사용하면 오히려 성능을 저하시킬 수도 있음
인덱스의 장점과 단점을 이해하고, 언제 인덱스를 활용해야 하는지 판단하는 것이 중요

인덱스가 성능을 향상시키는 경우
데이터 조회(SELECT) 속도 향상
WHERE, JOIN, ORDER BY, GROUP BY 같은 연산이 포함된 쿼리 최적화
대량의 데이터를 검색할 때, 특정 컬럼을 기준으로 빠르게 탐색 가능

인덱스가 성능을 저하시킬 수 있는 경우
크기가 작은 데이블에서 WHERE 검색(FULL SCAN이 빠를 수 있음)
INSERT, UPDATE, DELETE 성능 저하
(자주 변경되는 컬럼에 인덱스를 생성하면, 인덱스 유지 비용 증가)

데이터 최적화

데이터가 많아질수록 데이터베이스의 성능을 유지하기 위해 데이터를 분할하는 기법이 필요함

샤딩(Sharding)

데이터를 여러 개의 독립적인 데이터베이스(샤드)로 나누어 저장

샤딩이 필요한 경우

• 데이터베이스가 너무 커서 하나의 DB서버에 저장할 수 없는 경우
• 전 세계 여러 지역에서 서비스를 운영하여 데이터 지역성을 최적화해야 하는 경우

파티셔닝(Partitioning)

하나의 데이터베이스 내에서 데이터를 여러 개의 파티션으로 분할
샤딩과 다르게 물리적으로 데이터베이스를 나누는 것이 아닌, 논리적으로 하나의 테이블을 여러 개의 파티션으로 나누는 방식
(수평 파티셔닝 / 수직 파티셔닝)

피티셔닝이 필요한 경우
특정 데이터가 너무 많아서 관리가 어려운 경우
특정 조건으로 자주 조회하는 데이터가 많아서, 검색 성능을 높이기 위해 데이터를 논리적으로 분리할 필요가 있는 경우