인덱스
1. 정의
-
DB 테이블에 대한 검색 성능의 속도를 높여주는 자료 구조
-
"인덱스" = "책에 있는 목차"
- 책에서 정보를 찾을 때, 먼저 원하는 카테고리를 목차에서 찾고 목차에 있는 페이지 번호를 보고 찾아가듯
-
블럭 (Block)
- 인덱스가 저장하는 최소 단위
- 데이터가 저장되는 최소 단위
2. 과정
- 특정 컬럼에 인덱스를 생성하면
해당 컬럼의 데이터들을 정렬하여, 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장됨 - 인덱스를 생성했으면
앞으로 쿼리문에 "인덱스 생성 컬럼을 Where 조건으로 거는 등"의 작업을 하면 옵티마이저에서 판단하여 생성된 인덱스를 탈 수가 있음 - 만약 인덱스를 타게 되면
(아래의 그림과 같이) 인덱스를 타게 되고, 먼저 인덱스에 저장되어 있는 데이터의 물리적 주소로 가서 데이터를 가져오는 식으로 동작
이를 통해, 검색 속도의 향상을 가져올 수 있음
3. 장단점
장점 (필요성/사용목적)
"데이터들의 정렬"로 조건 검색에서 장점을 가짐
-
조건 검색 Where 절의 효율성
풀 테이블 스캔(데이터를 찾을 때 레코드의 처음~끝 다 읽는 것)해서, 검색 조건과 맞는지 비교하는 것은 비효율적그러나, 인덱스 테이블은 데이터들이 정렬되어 저장되므로, 조건에 맞는 데이터를 빠르게 찾을 수 있음
-
정렬 Order by 절의 효율성
Order by는 정렬과 동시에 메모리상에서 정렬(Sort과정)이 이루어지기 때문에 부하 多 걸림그러나, 인덱스는 이미 정렬된 데이터를 가져오기만 하기 때문
-
MIN, MAX의 효율적인 처리가 가능
풀 테이블 스캔(데이터를 찾을 때 레코드의 처음~끝 다 읽는 것)은 비효율적그러나, 인덱스는 MIN값과 MAX값을 레코드의 시작값과 끝 값 한건씩만 가져오면 되기 때문
단점
-
정렬된 상태 계속 유지 필요
데이터가 추가되거나 값이 바뀐다면(INSERT, UPDATE, DELETE를 통해)
인덱스 테이블 내에 있는 값들을 다시 정렬을 해야 함
++ 인덱스 테이블, 원본 테이블 이렇게 두 군데에 데이터 수정 작업해줘야 한다는 단점도 존재 -
테이블의 전체 데이터 중에서 10~15% 이하의 데이터를 처리하는 경우에만 효율적
그 이상의 데이터를 처리할 땐 인덱스를 사용하지 않는 것이 더 낫다.
++ 인덱스를 관리하기 위해서는 데이터베이스의 약 10%에 해당하는 저장공간이 추가로 필요
복합 인덱스
1. 정의
-
인덱스 키를 여러개 잡는 것
- 이때, 복합 인덱스의 열순서를 어떻게 정하는지에 따라 성능이 달라질 수 있음
-
두 개 이상의 컬럼을 합쳐서 인덱스를 만드는 것
-
예시
- A,B,C 의 복합인덱스가 있는데 B, C 만 조회 조건이 걸리면 조회가 되지 않음
참고: [DB] 데이터베이스 인덱스(Index) 란 무엇인가?
참고: 인덱스 기본개념
참고: DB 인덱스를 설정하면 왜 빨라지나?
참고: [DB 6편] MySQL 인덱스 성능 관련 정리 (prefix, 복합인덱스)
