DB 인덱스

인덱스란

인덱스는 DB 테이블에 대한 검생 성능을 높여주는 데이터 구조다. 존재하는 테이블 위에 구축한다. 예를 들어 기존 테이블이 책 본문이라고 한다면, 인덱스는 책의 목차 페이지다.

특정 데이터를 DB에서 조회한다고 했을 때, 해당 데이터가 어디에 있는지 모르기 때문에 full scan을 하게 된다. 하지만 이미 Index로 정렬된 상태라면 어느 위치에 있는지 잘 알기 때문에 빠르게 데이터를 찾을 수 있다.

인덱스의 작동 순서는 이렇다.

1. 인덱스로 간다
2. 인덱스에 저장된 데이터의 물리 주소 참조
3. 데이터의 물리 주소로 가서 데이터를 가져온다

)
(도표 출처 : https://coding-factory.tistory.com/746)

인덱스의 종류

1. B+Tree Index
2. Bitmap Index
3. IOT(Index Organized Table) Index
4. Clustered Index
5. etc...

DB마다 제공하는 인덱스 종류가 다름

인덱스는 어디에 쓰면 좋은가

• 조건 Where 절에 주로 사용하는 컬럼 : 데이터 생성 시 이름 순으로 정렬되지 않고 뒤죽박죽 저장되기 때문에 결국 Fullscan을 해야 함. Index 테이블은 정렬을 해두기 때문에 빠르게 찾을 수 있음
• 정렬 Order by 절에 주로 사용하는 컬럼: 인덱스는 이미 정렬되어 있기에 바로 따로 Order by 작업을 수행할 필요가 없음
• Min, Max절에 주로 사용하는 컬럼 : 인덱스는 이미 정렬 되어있기에 처음과 끝을 따로 찾을 필요가 없다
• =으로 비교하는 컬럼
• 중복도가 낮은 컬럼(Cardinality가 높은 컬럼)
• JOIN에 자주 사용하는 컬럼

인덱스의 문제점

인덱스 테이블 내 레코드 데이터가 자주 바뀌는 것이 문제

• 인덱스 테이블 재정렬 해주어야 하고
• 원본 테이블과 인덱스 테이블 모두 최신화 해야하고
• 인덱스 관리를 위해 DB의 10%에 해당하는 저장공간이 추가로 필요

참고 블로그에 따르면 전체 중 15% 미만 비중의 데이터만 처리할 경우 인덱스 테이블이 효율적이라고 함.

Index 생성하기(PostgreSQL)

# employees 인덱스 생성
create index employees_name on employees(name);

여기서 인덱스 이름은 employees_name이고 인덱스를 설정할 컬럼은 employees 테이블의 name이다.

# 인덱싱 적용 후 name 조건으로 조회
# 속도가 약 78ms -> 1.5 ms로 개선되었다

postgres=# explain analyze select id, name from employees where name = 'Zs';

QUERY PLAN

Bitmap Heap Scan on employees (cost=4.47..27.93 rows=6 width=10) (actual time=0.228..1.
508 rows=28 loops=1)
Recheck Cond: (name = 'Zs'::text)
Heap Blocks: exact=27
-> Bitmap Index Scan on employees_name (cost=0.00..4.47 rows=6 width=0) (actual time
=0.205..0.205 rows=28 loops=1)
Index Cond: (name = 'Zs'::text)

Planning Time: 0.673 ms
Execution Time: 1.554 ms
(7 rows)

Reference

• https://velog.io/@bsjp400/Database-DB-%EC%9D%B8%EB%8D%B1%EC%8B%B1Indexing%EC%9D%B4%EB%9E%80
• https://coding-factory.tistory.com/746