데이터베이스에서 인덱스(Index)란 책의 목차처럼 테이블 내 원하는 데이터를 빠르게 검색할 수 있도록 별도로 만들어 놓은 데이터 구조를 의미합니다.

예시를 들어보면, 인덱스는 색인(索引)과 유사합니다.

색인: 책의 뒤에 붙어 있는 '찾아보기' 목록

원본 테이블은 그대로 두고, 자주 조회하는 컬럼에 대한 값과 실제 데이터의 위치(ROW)를 매핑해 둡니다. 매핑해둔 덕분에 전체 테이블(Full Table Scan) 대신, 인덱스를 통해 찾으려고하는 행이 저장된 페이지로 바로 찾아가므로, 읽기(SELECT) 성능이 크게 향상됩니다.

B-Tree 인덱스

• 범위 검색(>, <, BETWEEN)에 최적화된 균형 트리 구조
• 다양한 검색 패턴 지원하지만, 생성/수정 시 오버헤드가 큼

해시(Hash) 인덱스

• 정확한 값 검색(=)에 최적화된 해시 테이블
• 등치 비교(=) 쿼리 속도 빠르지만, 범위 검색(>, <, BETWEEN) 불가

비트맵(Bitmap) 인덱스

• 비트맵을 사용하여 대량의 데이터에서 중복 값이 낮은 컬럼에 최적화된 인덱스
• 데이터 변경 시 오버헤드가 커서, 빠른 AND/OR 연산 수정이 많이 발생한느 테이블에 부적합

복합(Composite) 인덱스

• 여러 컬럼을 조합하여 생성한 인덱스
• 자주 함께 쓰이는 최소한의 컬럼만 묶어 복합 인덱스를 생성하는 것이 좋음

• 조회가 느리고, 자주 실행하는 쿼리에서 WHERE, JOIN, ORDER BY, GROUP BY 등에 사용되는 컬럼에 인덱스를 걸어두면 조회 성능을 크게 개선할 수 있습니다.
• 데이터가 많아서(수십만에서 수백만 건 이상일 경우) 전체 탐색이 부담될 때, 인덱스 없이 전체 스캔은 매우 느립니다. 이때 인덱스를 사용하면 성능을 크게 개선할 수 있습니다.
• INSERT / UPDATE / DELETE와 같이 쓰기 작업 비용 증가합니다. 인덱스도 함께 갱신되므로 쓰기 성능이 떨어질 수 있습니다.
• 인덱스 자체가 별도의 데이터 구조이므로 디스크 공간을 추가적으로 사용합니다.

인덱스는 읽기 성능을 비약적으로 개선해긴 하지만, 쓰기 성능 저하와 저장 공간 증가라는 트레이드오프(trade-off)가 있습니다. 따라서 실제 적용할때는 무조건 느리다고 적용하면 안되고, 꼭 필요하고 적용하면 효과적인 컬럼에만 인덱스를 적용하는 것이 좋습니다.