Index

Q . Index 란?

RDBMS에서, 테이블에 대한 검색 속도를 향상시키는 자료 구조

테이블 내의 컬럼 1개, 또는 여러 개의 컬럼을 이용하여 생성 가능

 

https://mangkyu.tistory.com/96

 

 

- 해당 컬럼을 정렬 후 별도 공간에 이를 저장하여, 검색 시 테이블의 레코드를 full scan하지 않고 색인화 되어 있는 index 파일을 검색하여 검색 속도를 빠르게 함.

 

원하는 값을 탐색하는 속도가 빠름

 

 

 

Q . index의 장단점

 

장점

데이터들이 정렬된 형태를 갖고, 따라서 검색의 속도를 향상시킴

 

 

단점

- 인덱스가 Database의 10% 내외의 공간을 필요로 하므로, 이에 따른 추가적인 공간이 필요함

- 테이블의 데이터가 변경될 때 인덱스를 재작성해야 하므로 성능이 떨어짐

 -> SELECT를 제외한 동작(INSERT, UPDATE, DELETE)의 성능에 악영향을 끼침

 

 

 

Q . 인덱스를 사용해야 하는 경우

 - 데이터의 양이 많고, 검색 작업이 수정 작업보다 빈번하게 일어나는 경우

 

(1) where 절에서 자주 사용되는 column

 

(2) 외래키가 사용되는 column

 

(3) join에 자주 사용되는 column

 

-> 조회 작업이 자주 일어나는 column

 

 

 

Q . 사용을 피해야 하는 경우

 - 테이블의 데이터를 업데이트할 때 인덱스를 재작성해야 하므로 성능이 떨어짐

 

(1) Data 중복도가 높은 column

 - 해당 column을 통하여 데이터를 검색해야 하는데 중복도가 높으면 검색의 효율이 떨어짐

 

(2) DML(INSERT, DELETE, UPDATE,, )이 자주 일어나는 column

 - INSERT 

데이터가 순서대로 정렬되어 있어야 하는 인덱스에서, 새로운 데이터가 입력되는 경우

기존 인덱스 블록의 일부를 새 블록에 기록한 후, 그로 인해 생긴 기존 블록의 빈 공간에 새로운 데이터를 추가함.

-> index split ( 인덱스의 블록이 두개로 나누어지는 현상.)

--> 성능 면에서 저하

 

 

 - DELETE

테이블에서 데이터가 삭제되는 경우, 지워진 후 다른 데이터가 그 공간을 활용할 수 있음
But 인덱스에서 데이터가 삭제되는 경우, 지워지지 않고 사용 안 됨 표시가 된다.

따라서 삭제 연산이 많아지면

-> 테이블 데이터 수에 비하여 인덱스의 데이터가 지나치게 많아질 수 있음

--> 인덱스를 사용함을 통한 수행 속도를 기대하기 어려워짐

 

 

 - UPDATE

인덱스에는 UPDATE 개념이 존재하지 않음.

DELETE가 수행된 후, 새로운 데이터 INSERT가 수행됨

 

 

 

Q . Index 의 성능을 향상시키는 방법이란?

카디널리티(Cardinality)

: 한 컬럼이 갖고 있는 값의 상대적인 중복 정도

-> 카디널리티가 높을수록(중복 정도가 낮을수록) 좋은 column

 

 

선택도(Selectivity)

: 특정 값을 얼마나 잘 선택할 수 있는지에 대한 지표

  특정 필드 값을 지정했을 때, 선택되는 레코드 수를 테이블 전체 레코드 수로 나눈 것

select count(1) from students where last_name="kim";

select count(1) from students where id=1;

-> 중복 정도가 적을수록 선택도가 낮음

--> 선택도가 낮을수록 좋은 column

 

 

활용도

: 해당 컬럼이 작업에서 얼마나 활용되는지에 대한 값

 (쿼리를 날릴 때, where절에 자주 사용되는지)

-> 활용도가 높을수록 좋은 column

 

 

 

 

 

 

Q . Index 자료구조

Hash 인덱스 알고리즘

컬럼의 값을 해싱한 값을 기반으로 인덱스를 구현.

-> 매우 빠른 검색 지원 (시간복잡도 O(1) )

값을 변형하여 인덱싱하기 때문에 값의 일부분으로 검색하는 등의 작업은 불가능하고,

같은 이유로 연속적인 데이터에 대한 순차 검색(부등호를 통한 비교 등..)이 불가능

 

 

B+Tree 인덱스 알고리즘

일반적으로 사용되는 알고리즘.

B-Tree(Balanced Tree, 편향되지 않은 트리)를 개선시킨 자료구조 B+Tree를 사용함

- leaf node에만 데이터가 저장됨.

  -> 데이터의 순회 속도를 높임(리프노드들을 LinkedList로 연결하여, 순차 검색을 용이하게 함)

 

B-Tree (https://rebro.kr/167)

B+Tree(https://rebro.kr/167)

 

 

Q . 해시 알고리즘보다 B+ Tree를 이용한 인덱스를 많이 쓰는 이유는?

B+Tree는 검색 작업에 있어서 해시보다는 비효율적인 시간복잡도를 가진다.(트리를 사용하기 때문에 O(logN))

하지만 해시의 데이터들은 정렬되어 있지 않고,

B+Tree에서는 해시와는 다르게 순차 검색 연산을 효율적으로 수행할 수 있다.

 

이는 순차 검색 연산을 이용한 등호 연산(<, >)이 자주 발생하는 인덱스에서 큰 강점이기 때문에,

해시 알고리즘 보다는 B+Tree를 이용한 인덱스가 주로 사용된다.

 

 

 

++

Q . Primary index(기본 인덱스) vs Secondary index(보조 인덱스)

 

primary index(클러스터형 인덱스)

기본 키를 포함하는 인덱스(테이블 당 하나씩만 존재)

인덱스가 레코드와 직접적으로 연결되어 위치를 결정

(키의 순서가 레코드의 순서를 결정지음. 정렬되어 있음)

 

secondary index(비클러스터형 인덱스)

"보조하는" 인덱스

일반적으로 속성에 unique가 지정된 컬럼이 보조 인덱스 역할을 함

테이블 당 여러 개의 보조 인덱스 생성 가능

 

레코드의 위치를 결정짓지는 않음.(정렬되어 있지 않음)

레코드의 위치가 어딘지를 알려주는 역할.(포인터를 갖고 있음)

 

 

 

 

 

[DB] 11. 인덱스(Index) - (1) 개념, 장단점, B+Tree 등 (rebro.kr)

[DB] 11. 인덱스(Index) - (1) 개념, 장단점, B+Tree 등