Index란?

Index란?

인덱스는 말 그대로 책의 맨 처음 또는 맨 마지막에 있는 색인이라고 할 수 있다. DBMS는 DB 테이블의 모든 데이터를 검색해서 원하는 결과를 갖고 오려면 오래 걸리는데, 이를 빠르게 처리하기 위해 칼럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 인덱스를 만들어 두어 값을 빠르게 탐색한다.

하지만 새로운 값을 추가하거나 삭제, 수정 시 쿼리문 실행 속도가 느려지는데 저장 성능을 희생하고 데이터의 읽기 속도를 높이는데 포커스를 맞춘 것이다.

삽입 삭제 수정 시 정렬이 된 상태로 저장이 되어야하는데 원래 있던 데이터에서 여러가지 변경해야할 비용이 발생하여 이때에는 인덱스는 효율적이지 않다.

Index 자료구조

• B+ Tree 인덱스 알고리즘

일반적으로 사용되는 인덱스 알고리즘은 B+ Tree 인덱스는 칼럼의 값을 변형하지 않고(사실 값의 앞부분만 잘라서 관리한다.) 원래의 값을 이용해 인덱싱하는 알고리즘이다.

B - tree

1. 루트 노드에서 시작하여 key들을 순회하면서 검사합니다.1-2. 검색하는 값과 key들의 대소관계를 비교해봅니다. 어떠한 key들 사이에 k가 들어간다면 해당 key들 사이의 자식 노드로로 내려갑니다.
2. 1-1. 만일 k와 같은 key를 찾았다면 검색을 종료합니다.
3. 해당 과정을 리프노드에 도달할 때까지 반복합니다. 만일 리프노드에도 k와 같은 key가 없다면 검색을 실패합니다.

• Hash 인덱스 알고리즘

칼럼의 값으로 해시 값을 계산해서 인덱싱하는 알고리즘으로 매우 빠른 검색을 지원한다. 하지만 값을 변형해서 인덱싱하므로, 특정 문자로 시작하는 값으로 검색을 하는 전방 일치와 같이 값의 일부만으로 검색하고자 할 때는 해시 인덱스를 사용할 수 없다. 주로 메모리 기반의 데이터 베이스에서 많이 사용한다.

• 인덱스에서 B+ Tree를 사용하는 이유

데이터 접근하는 시간복잡도가 O(1)인 hashtable이 더 효율적일 것 같지만 SELECT 질의의 조건에는 부등호(<>) 연산도 포함이 된다. hashtable을 사용하게 된다면 등호(=) 연산이 아닌 부등호 연산의 경우에 문제가 발생한다. 동등 연산(=)에 특화된 hashtable은 데이터베이스의 자료구조로 적합하지 않다.

Primary Index vs Secondary Index

클러스터란 여러개를 하나로 묶는다는 의미로 주로 사용되는데 클러스터드 인덱스도 크게 다르지 않다. 인덱스에서 클러스터드는 비슷한 것들을 묶어서 저장하는 형태로 구현되는데, 이는 주로 비슷한(물리적으로 인접한 장소에 저장되어 있는 데이터) 값들을 동시에 조회하는 경우가 많다는 점에서 착안 된 것이다.

클러스터드 인덱스는 테이블의 프라이머리 키에 대해서만 적용되는 내용이다. 즉 프라이머리 키 값이 비슷한 레코드끼리 묶어서 저장하는 것을 클러스터드 인덱스라고 표현한다. 클러스터드 인덱스에서는 프라이머리 키 값에 의해 레코드의 저장 위치가 결정되며 프라이머리 키 값이 변경되면 그 레코드의 물리적인 저장 위치 또한 변경되어야 한다. 그렇기 때문에 프라이머리 키를 신중하게 결정하고 클러스터드 인덱스를 사용해야 한다.

클러스터드 인덱스는 테이블 당 한 개만 생성할 수 있다. 프라이머리 키에 대해서만 적용되기 때문이다, 이에 반해 non 클러스터드 인덱스는 테이블 당 여러 개를 생성할 수 있다.

Composite Index

인덱스로 설정하는 필드의 속성이 중요하다. title, author 이 순서로 인덱스 설정한다면 title을 search 하는 경우, index를 생성한 효과를 볼 수 있지만, author 만으로 search 하는 경우, index를 생성하는 것이 소용이 없어진다. 따라서 SELECT 질의를 어떻게 할 것인가가 인덱스를 어떻게 생성할 것인가에 대해 많은 영향을 끼치게 된다.

고려 사항

• INSERT, DELETE, UPDATE 쿼리문을 실행할 때 별도의 과정이 추가됨 결코 인덱스를 생성한다고 빠른 것 만은 아님
• 컬럼을 이루고 있는 데이터의 형식에 따라서 인덱스의 성능이 악영향을 미칠 수 있음, 데이터의 형식에 따라 인덱스를 만들면 효율적이고 만들면 비효율적인 데이터의 형식이 존재한다는 것이다.
  • ex) 이름 나이 성별 중 값의 range가 적은 성별은 인덱스를 읽고 다시 한번 디스크 I/O가 발생 비효율적

인덱스 테이블?

인덱스 테이블은 다음과 같이 생겼는데

create index i_email
    on member (email);

다음과 같은 SQL 문으로 만들 수 있다. 

 

정렬된 상태로 위와 같은 속도로 빠르게 접근하여 데이터를 찾은 후 실제 데이터에 접근하여 인덱스 테이블에서 찾은 정보와 일치하는 데이터들만 가져오므로 매우 빠르게 데이터를 찾아올 수 있다. 

 

마침.

 

Ref.

 

https://jojoldu.tistory.com/476

1. 커버링 인덱스 (기본 지식 / WHERE / GROUP BY)