08. 04 TIL : RDB 인덱스의 내부 작동 원리

문제 : 업무 중 DB를 검색하다 어떤 테이블을 봤을 때 클러스터형 인덱싱이 되어 있지 않은 것을 알게 되었다. 그 테이블의 데이터를 보다 깔끔하게 조회하려면 ORDER BY를 통해 정렬한 후 조회해야 했다. 왜 그렇게 테이블을 설계한 것인지가 궁금해졌고, 마침 공부하던 SQL책에서 관련 내용이 나와 정리해보려고 한다

시도해본 것 : 특별히 있진 않다. 어려운 문제가 아니고 다만 왜 클러스터형 인덱싱을 하지 않아 정렬하지 않은 이유가 있을 것인데, 왜 그런 판단을 내리게 된 것인지 그 근거와 이유를 이해하는 것이 더 중요하다 생각했다

 

0. 균형 트리

- 인덱스는 균형 트리 자료구조로 만들어지고, 균형 트리는 검색 연산 시 무조건 루트 노드(MySQL : 페이지)부터 검색한다. 루트 노드에 각 노드에 대해 정렬된 인덱스가 있어 필요한 노드만 검색할 수 있어 원하는 데이터를 찾기 위해 더 적은 검색 연산을 수행해서 결과를 찾을 수 있다.

1. 하지만 인덱스를 추가하면

노드 분할(페이지 분할) 작업이 수행되기 때문에 데이터 편집 작업 시 더 느려지게 된다. 노드 분할이란, 새로운 노드를 준비해서 데이터를 나누는 작업을 의미한다. 이 작업을 수행하며 DB가 느려지고, 너무 자주 일어나면 성능에 영향을 준다

~ 기존의 노드에 할당된 공간이 다 차게 된 후, 새로운 데이터가 입력될 때 루트 노드에 인덱스 데이터가 추가되고 새로운 노드가 만들어지며 해당 데이터가 첫 번째로 입력된다. 이 과정이 진행되며 루트 노드도 꽉차게 되면, 루트 노드도 새롭게 페이지 분할을 하고 기존의 루트 노드 위에 새로운 루트 노드가 생긴다. 또한 하위에도 지금 입력되는 데이터의 노드가 새로 생겨나게 된다. 이처럼 인덱싱을 하면 데이터 변경 시, 인덱스를 사용하지 않았을 때보다 훨씬 더 많은 작업이 필요하다

2. 인덱스 구조

1) 클러스터형 인덱스

자동으로 정렬해주는 인덱스. PK 지정 시 구성된다 ~ 책의 시작에 "목차"와 같은 기능

2) 보조 인덱스

고유 키 제약조건(UNIQUE)이 보조 인덱스를 생성한다.데이터를 정렬하지 않는다 ~ 책 뒷부분의 "찾아보기"와 같은 기능

3. 인덱스에서 데이터 검색하기

클러스터형 인덱스인 루트 노드를 먼저 검색한다. 그리고 해당하는 리프 노드로 타고 들어가 해당 데이터를 검색한다. 보조 인덱스를 사용해 데이터를 검색할 경우, 루트 노드를 검색하고 해당 데이터가 있는 리프 노드를 검색한 뒤, 데이터 노드로 가서 해당 데이터를 찾는다. 클러스터형 인덱스가 조금 더 검색속도가 빠르다

 

알게된 것

데이터의 편집이 빈번하게 일어나는 노드에 대해서는 인덱스를 넣지 않는 것이 성능에 더 좋다는 것을 알게 되었고, 그런 경우에 정렬을 위해선, ORDER BY 구문 등을 활용해 데이터를 정렬해야 한다