[12주차 주간 발표] 인덱스

 

 

인덱스

데이터를 좀 더 빠르게 찾을 수 있도록 도와주는 도구이다.

 

장점

• 검색 속도가 빨라질 수 있다. 데이터의 중복성이 낮을수록 속도가 더 빠르다.
• 쿼리의 부하가 줄어들어 시스템 전체 성능이 향상된다.

단점

• 데이터베이스 크기의 10% 정도의 추가적인 공간이 필요하다.
• 데이터의 변경 작업(삽입, 수정, 삭제)이 자주 일어나면 성능이 나빠질 수 있다.

 

클러스터형 인덱스

테이블 당 한 개만 지정 가능하고, 클러스터형 인덱스로 지정한 열에 맞춰 자동으로 오름차순 정렬된다.

데이터 자체가 인덱스 역할을 한다.

1. 기본키로 지정하거나
2. 기본키로 설정된 열이 없을 때 유니크와 NOT NULL으로 설정한 경우

자동으로 클러스터형 인덱스가 생성된다.

기본키와 유니크 NOT NULL이 둘 다 있으면 기본키로 지정한 열에 클러스터형 인덱스가 생성된다.

B-Tree 구조를 가짐

AAA부터 FFF 이전의 값까지 첫 번째 리프 페이지에 저장되고, FFF부터 LLL 이전의 값까지 두 번째 리프 페이지에 저장되고, LLL부터 그 이후의 값들이 세 번째 리프 페이지에 저장되는 예시이다.

 

이제 III라는 데이터를 삽입해 보자.

오름차순으로 정렬되기 때문에 HHH와 JJJ 사이에 I가 삽입되어야 한다. 따라서 JJJ가 한 칸 이동된다.

 

이제 GGG라는 데이터를 삽입해 보자. GGG는 FFF와 HHH 사이에 위치해야 하는데 빈 공간이 없으므로 페이지 분할이 일어난다.

분할된 페이지

인덱스를 사용했을 때, 삽입문이 자주 발생하면 속도가 저하되는 문제가 이 페이지 분할 때문이다.

이해를 위해 주소값은 적지 않고 그렸었지만 실제 테이블 구조는 위 그림처럼 루트 페이지에 리프 페이지의 주소 값을 저장해 놓는다.

그리고 리프 페이지에는 실제 데이터가 저장되어 있다. 데이터 자체가 인덱스 역할을 한다는 말이 이 뜻이다.

 

보조 인덱스

하나의 테이블에 여러 개를 생성할 수 있다.

보조 인덱스도 인덱스 페이지는 정렬되어야 한다. 클러스터형 인덱스와 다른 점은 리프 페이지에 실제 데이터가 저장되는 것이 아니라 데이터가 저장되어 있는 위치(Row ID)를 가지고 있다는 점이다. 클러스터형 인덱스보다 메모리를 한 번 더 읽어야 하기 때문에 데이터를 찾는 속도는 느려진다.

데이터를 삽입이 일어나면 데이터 페이지의 마지막에 삽입하고, 리프 페이지에 보조 인덱스 컬럼의 값을 추가한다.

리프 페이지의 데이터 크기가 데이터 페이지의 데이터 크기보다 훨씬 작기 때문에 클러스터형 인덱스에서 페이지가 분할되는 것보다 보조 인덱스에서 페이지가 분할되는 것이 더 부담이 적다. 따라서 보조 인덱스가 클러스터형 인덱스보다 데이터 삽입에 유리하다.

 

 

결론

• WHERE 절에서 사용되는 열에 인덱스를 만들어야 한다.
  • 테이블 조회 시 WHERE 절의 조건에 해당 열이 나오는 경우에만 인덱스를 주로 사용하기 때문이다.
• WHERE 절에 사용되더라도 SELECT 문이 자주 사용되어야 효과적이다.
• 데이터 중복도가 높은 열은 인덱스를 만들어도 효과가 없다. 
  • 인덱스의 관리 비용 때문에 인덱스가 없는 편이 나을 수도 있다.
• 외래키로 지정한 열에는 자동으로 외래키 인덱스가 생성된다.
• JOIN에 자주 사용되는 열에는 인덱스를 생성해 주는 것이 좋다.
• 클러스터형 인덱스를 생성할 열은 범위(BETWEEN, >, < 등)로 사용하거나 집계 함수를 사용하는 경우에 유리하다.
• 클러스터형 인덱스가 테이블에 아예 없는 것이 좋은 경우도 있다.
• 공간 확보 및 데이터를 입력할 때 발생되는 부하를 줄이기 위해 사용하지 않는 인덱스는 제거해야 한다.