인덱스의 개념
- 자주 사용되는 칼럼으로 생성해 테이블 전체를 찾지 않고도 데이터 조회 동작 속도를 높여주는 자료구조
- 인덱스가 설정되지 않으면 Table Full Sacn이 일어나 성능이 저하되거나 치명적인 장애로 이어질 수 있다.
- 사용자가 직접 접근할 수는 없고, 검색과 질의에 대한 처리에만 사용된다.
- 조회속도는 빨라지지만 쓰기(INSERT, UPDATE, DELETE)속도는 별도의 자료구조의 수정도 필요하므로 낮아진다.
- 인덱스를 저장하기 위한 데이터베이스 전체 크기의 10%정도의 저장공간도 필요하다.
- 위와 같은 특징들로 인해 수정보다 검색이 필요한 테이블에서 사용한다
인덱스의 특징
- 인덱스는 하나 혹은 여러개의 컬럼에 대해 설정할 수 있다.
- WHERE절을 사용하지 않고 인덱스가 걸린 컬럼을 조회하는 것은 Full Sacn이므로 성능에 영향이 없다.
인덱스 자료구조
B- tree
대부분의 RDBMS 구현체의 기본으로 사용되는 자료구조
- 완전 이진 트리와 유사하지만, 한 노드당 자식 노드가 두 개 이상이 가능하다.
- 노드 당 자식의 개수가 여러개이기 때문에 완전 이진트리보다 더 빠른 탐색속도를 가진다.
- 인덱스 컬럼(키)을 관리를 하고 최상위에 루트노드, 가장 끝단에 리프 노드가 있고, 사이에는 브랜치 노드가 있다.
- Clustered, Non Clustered Index 종류에 따라 리프노드에 데이터가 있거나, 데이터의 주소를 가지고 있다.
B-tree는 루트노드부터 리프노드까지의 거리가 일정한 균형 트리인데, 테이블의 수정작업(INSERT, UPDATE, DELETE)의 반복을 통해 균형이 깨지고, 성능도 악화된다. 어느정도는 자동으로 균형을 회복하지만, 갱신이 자주 이루어지면 인덱스 재구성을 통해 트리의 균형을 찾거나, 인덱스의 적용 유무를 생각해봐야 한다.
인덱스 종류
Clustered Index
- 데이터가 정렬된(PK 또는 UNIQUE NOT NULL 컬럼 기준 오름차순) 상태로 저장
- 테이블 당 한개만 생성
- 제약조건 PRIMARY KEY, UNIQUE NOT NULL에 의해 자동으로 생성(둘다 있으면 PK 우선순위 Clustered Index 설정)
- 데이터 검색 순서
- 루트 노드 > 브랜치 노드 > 리프 노드(==데이터 페이지)
- 리프노드 자체가 데이터이므로 인덱스 순서와 물리적 순서가 일치하고, 변경(INSERT, UPDATE, DELETE)이 느림
Secondary Index
- 테이블에 보조 인덱스 생성 가능
- 제약조건 UNIQUE에 의해 자동으로 생성
- 테이블 당 여러개 생성가능
- 데이터 검색 순서
- 루트 노드 > 브랜치 노드 > 리프 노드 > 데이터 페이지(힙 페이지)
- 리프노드가 데이터의 참조값을 갖고 있기에 인덱스 순서가 물리적 순서와 일치하지 않고, 변경(INSERT, UPDATE, DELETE)이 비교적 빠름
