Index란?
Index는 데이터베이스에서 검색 성능을 높여주는 대표적인 방법으로, 마치 책의 끝에 있는 색인처럼 특정 값을 빠르게 찾기 위해 사용되는 자료구조입니다. 인덱스를 사용하면 전체 테이블을 처음부터 끝까지 탐색하는 Full Table Scan 대신 Index Scan을 통해 데이터가 위치한 곳을 빠르게 찾아낼 수 있습니다.
Index 구조
Index는 BTree, B+Tree, Hash, Bitmap으로 구현될 수 있습니다. 하지만, 일반적으로 RDBMS에서는 B+Tree 자료구조 형태의 인덱스를 가장 많이 사용합니다. Index를 생성하게 되면 특정 Column의 값을 기준으로 정렬하고, 데이터의 물리적 위치를 함께 별도의 파일로 저장합니다. 이때, Index에 저장되는 속성 값을 'Search-Key', 실제 데이터의 물리적 위치를 'Pointer'라고 합니다.
이제, 그림을 통해 Index가 어떻게 데이터 정렬 상태를 유지하며 효율적인 검색 수행이 가능한지 알아보도록 하겠습니다.
Index는 위 그림과 같이 데이터를 저장 및 관리합니다. 그림을 보면 포인터를 이용해 자신보다 우선순위가 낮거나 높은 위치를 가리키고 있는 것을 알 수 있습니다. 다음과 같은 쿼리를 수행한다고 했을 때, 다음 그림과 같이 포인터를 활용하여 효율적인 탐색을 수행합니다.
Index의 종류
클러스터링 인덱스
클러스터링형 인덱스란 특정 Column을 기본키로 지정하면 자동으로 생성되는 인덱스를 의미합니다. 해당 Column을 기준으로 정렬이 수행됩니다.
논 클러스터링 인덱스
보조 인덱스란 Create Index 또는 Unique Key로 지정하여 생성된 인덱스를 의미합니다.
Index를 사용하는 이유
데이터베이스 테이블에 지속적으로 데이터를 추가하다 보면 내부적으로는 특정 순서 없이 데이터가 저장이 이루어집니다. 이때. 특정 조건에 해당하는 데이터를 찾으려면, 기본적으로 테이블 전체를 훑는 Full Table Scan이 필요합니다. 그러나 특정 Column에 인덱스를 생성해두면 해당 Column의 값들이 정렬된 상태로 저장 및 관리되므로, 해당 Column을 조건으로 검색할 때 빠르게 데이터를 찾을 수 있습니다. 결과적으로, 쿼리 성능을 크게 높일 수 있다는 점이 인덱스를 사용하는 주된 이유입니다.
장단점
장점
- 검색 속도 향상
- Index 테이블을 통해 특정 Column을 정렬된 상태로 유지하여 빠른 검색 수행
단점
- 추가 저장공간 필요
- Index 자료구조를 저장하기 위한 공간이 필요하며, 일반적으로 테이블 크기의 약 10% 수준의 추가적인 저장공간이 소모
- 느린 데이터 변경 작업
- B+Tree 구조의 Index는 데이터가 추가, 갱신, 삭제될 때마다 트리 구조를 갱신해야 하므로 쓰기 작업에 대한 성능 저하 발생
Index를 효과적으로 사용하는 방법
데이터 중복
True/False 또는 남/여와 같이 데이터 중복이 많이 발생하는 속성은 Index로 생성하지 않는 것이 좋습니다. 일반적으로 선택도(조건을 만족하는 행의 비율)가 낮을수록 유리합니다.
조회 활용도
SELECT나 WHERE 절에서 자주 사용되는 컬럼 혹은 JOIN 조건으로 자주 사용되는 컬럼에 인덱스를 생성하면 쿼리 성능이 크게 향상됩니다.
수정 빈도
데이터 변경 시 마다 인덱스를 갱신해야 하므로 수정 빈도가 낮을수록 인덱스 효과가 좋아집니다.
데이터 양
대용량 데이터 테이블일수록 인덱스를 통해 얻는 검색 성능 개선 효과가 더 커집니다.
Index 갯수
한 테이블에 너무 많은 인덱스를 생성하면 데이터 수정 시 오버헤드가 크게 증가합니다. 일반적으로 4~5개 정도가 적정 범위로 권장됩니다.
예상 질문
인덱스란?
인덱스는 데이터베이스에서 빠른 데이터 검색을 위해 사용하는 자료구조입니다.
왜, 인덱스를 사용하면 빠르게 찾을 수 있나요?
Index는 Column 값과 이에 대한 위치를 Key-Value 형태로 관리하고 있습니다. 이를 활용해, 전체 테이블을 스캔하지 않고, 찾고자 하는 Column이 가지고 있는 위치를 알 수 있어 빠르게 접근할 수 있기 때문입니다.
인덱스의 내부 구조는 어떻게 되어 있나요?
B+Tree 자료구조를 사용하여 데이터를 관리하고 있습니다. B+Tree의 경우 조회 기능에 대하여 O(log N) 성능을 가지고 있어 빠른 조회가 가능합니다.
B+Tree는 어떻게 구현되어 있나요?
B+Tree의 가장 큰 특징은 데이터들이 정렬된 상태를 유지하며, Leaf Node에만 저장되어 있고 이들은 Linked List 형태로 연결되어 있다는 점 입니다. 이를 통해, 범위 검색 쿼리에 대하여 높은 성능을 유지할 수 있습니다.
Index를 Hash Table이 아닌 B+Tree로 구현하는 이유는 무엇인가요?
B+Tree는 Range Query에도 높은 성능을 보이기 때문입니다. Hash Table의 경우 단일 검색에 대해서는 O(1)의 성능을 보이지만, DB는 단일 검색만 수행하지 않습니다. 반면, B+Tree는 데이터들이 정렬된 상태를 유지하며 Linked List 형태로 연결되어 있기 때문에, 단일 검색과 범위 검색 모두 O(log N)의 성능을 가지고 있습니다.
Index를 많이 생성하면 안되나요?
Index를 생성하면 검색 성능이 향상될 수 있습니다. 하지만, Index를 관리하기 위한 저장 공간이 별도로 필요하며 추가/삭제/갱신 작업에 대한 오버헤드가 발생할 수 있습니다. 따라서, 추가 공간과 데이터 쓰기 작업에 소요되는 시간을 고려하여 생성하는 것이 좋습니다.
Index를 사용하면 성능이 좋아지니까 모든 컬럼에 사용하는게 좋은가요?
아닙니다. Index를 많이 사용하게 되면 추가 저장 공간이 필요하며 Index로 설정된 Column에 대한 쓰기 작업을 수행할 경우 이를 반영하기 위한 추가적인 작업으로 오버헤드가 발생하기 때문입니다.
true 또는 false 값을 갖는 Column에서 각각 1%, 99%의 비율로 구성된 상황에서 Index를 사용하는게 좋을까요?
True/False와 같은 값을 가지는 Column의 경우 중복도는 매우 높고, 선택도는 매우 낮으므로 Index로 생성하지 않는 것이 좋습니다.
클러스터링 인덱스와 논 클러스터링 인덱스는 무엇인가요?
클러스터링 인덱스는 기본키로 지정할 경우 자동으로 생성되는 인덱스이며 이를 기준으로 정렬을 수행합니다.
논 클러스터링 인덱스는 직접 생성한 인덱스나 Unique 설정에 의해 생성된 인덱스를 말합니다.
