인덱스

 인덱스라는 말은 실생활에서 책 앞단에서 많이 볼 수 있다. 목차라는 영어이다. 책으로 공부를 하면서 원하는 부분을 다시 보고 싶을 때가 있다. 그럴 때 목차를 통해 원하는 부분을 빠르게 볼 수 있다.

 그렇다면, DBMS에서 인덱스는 어떤 기능을 하고 언제 어떻게 사용하면 좋을지 개념 위주로 살펴보자!

 

 책과 DBMS에서 인덱스와의 공통점은 '정렬'이라는 것이다. 알파벳, 글자, 숫자 등 기준이 되는 것에 정렬이 되어 있다는 것이다. 바로 정렬이라는 것이 인덱스의 핵심이고 정렬을 통해 인덱스의 장점과 단점을 파악해볼 수 있다.

 

 그럼 자료구조와 비교해서 설명을 하면 인덱스는 SortedList 자료 구조이고, 데이터 파일은 ArrayList와 빗대어 볼 수 있다. 두 가지 차이는 정렬을 한다. 안한다의 차이이다. 그렇다면 인덱스의 장점을 SortedList 자료구조와 같이 정렬이 되어있기 때문에 원하는 데이터 값을 찾는 것에는 아주 좋은 성능을 보인다. 정렬, 즉 순서가 보장되어 있기 때문에 보다 빠르게 찾을 수 있다. 하지만, 정렬 상태를 유지하기 위해 새로운 데이터가 들어온다고 가정을 하면 다소 효율성이 떨어진다. 예를들어 1번 부터 100번까지 순서대로 앉아있는데, 38번에 해당하는 사람이 자리에 새로 들어가 앉을라면 뒤에있는 번호가 다 일어나서 옆으로 이동해야한다. 때문에 인덱스는 조회를 하는 select where 조건절에서는 탁월한 효율을 보이고 INSERT, DELETE, UPDATE와 같이 데이터를 수정하는 기능에서는 성능이 떨어져 오히려 역효과가 날 수 있다. 이렇듯 장단점이 극명하기 때문에 이를 잘 알고 활용할 필요가 있다. 

 

인덱스 사용 시 주의 사항

1) 사용하지 않는 인덱스는 삭제 -> 불필요한 인덱스는 오히려 INSERT, DELETE, UPDATE 에서 성능 저하 시킬 수 있다. 

 

2) 외래키를 지정한 열에는 자동으로 외래 키 인덱스가 생성이 된다.

 

3) where절에 사용되는 컬럼이라도 '자주' 사용돼야 인덱스의 가치가 있다.

 

4) where절에 '컬럼'에 연산을 사용한 경우 인덱스를 사용하지 않느다. 

    ex) SELECT * FROM user WHERE balance*10 < 100. -------(인덱스 사용 X)

          SELECT * FROM user WHERE balance < 100*10. -------(인덱스 사용 O)

 

데이터를 관리하는 방식(알고리즘)과 중복값 허용에 따라 여러가지로 나뉜다.

 데이터를 저장하는 방식(알고리즘)별로 구분할 경우 대표적으로 B-Tree와 Hash 인덱스로 구분할 수 있다. 

•  B-Tree는 이진트리가 아니라 밸런스드 트리로 노드가 2개 이상으로 한쪽에 치우쳐지지 않는 즉 균형잡힌 트리 자료구조라고 생각하면 된다. 역사가 오래된 만큼 성숙하고 가장 많이 쓰이는 방법이다. 그리고 B-Tree인덱스는 컬럼의 값을 변형하지 않고 원래의 값을 이용해서 인덱싱하는 알고리즘이다. 
• Hash인덱스는 컬럼의 값으로 해시값을 계산해서 인덱싱하는 알고리즘으로 매우 빠른 검색을 지원 하지만 값을 변형시키다 보니 값의 일부만 즉 범위 검색을 할 수 없다. 주로 메모리 기반 (Redis, mongoDB) 등 Nosql에서 자주 사용한다.

데이터의 중복 허용 여부로 분류하면 유니크인덱스와 논유니크인덱스로 나눌 수 있다. 실제 인덱싱하는 값이 1개인지 다수인지에 따라 최적화하는 방향이 크게 달라질 수 있다. 이것을 카디널리티라는 것으로 해석할 수 있는데, 카디널리티는 예를들어 남자와 여자로 인덱스로 나눈다면 다수의 사람들이 2가지로만 묶이니 카디널리티가 낮다고 보고, 고유의 번호인 주민번호는 카디널리티가 높다고 볼 수 있다. 따라서 카디널리티 수준에 따라서 인덱스 사용을 고려해보는 것도 디비 쿼리의 성능을 높이는 조건에 해당한다.

 

클러스터드 인덱스와 논클러스터드 인덱스

Clustered Index (무리를 이룬 index, 군집 인덱스)	Nonclustered Index(무리를 이루지 않은 인덱스, 비군집 인덱스)
-PK -테이블 당 1개만 존재 -인덱스의 데이터 페이지가 함께 존재 -리프 페이지(데이터) == 데이터 페이지 -데이터가 정렬 된 상태 -루트페이지, 브랜치 페이지, 리프페이지(데이터 페이지) 구조	-Secondary Key(보조키), 보조 인덱스 -테이블에 여러개 존재 가능 -Unique 제약 조건으로 컬럼을 생성하면 자동으로 생성 -인덱스와 데이터 페이지가 따로 존재    -> 때문에 리프 페이지에서 데이터가 있는 곳의 주소를 가짐    -> 그래서 데이터 페이지가 정렬되지 않아도 됨 -주소를 갖고 정렬이 되지 않았기 때문에 클러스터드 인덱스보다는 비교적 조회 속도가 느림 -하지만, insert/update/delete는 비교적 성능이 좋음

 

 

REFENCE

1. Real MYSQL 

2. https://www.youtube.com/watch?v=P5SZaTQnVCA 

3. https://www.youtube.com/watch?v=NkZ6r6z2pBg