IT/프로그램 | 앱

DBMS 의 INDEX 의 개념

DKSOFT 2019. 7. 3.

안녕하세요. 
디케이랩의 디케이입니다.

 

오늘은 좀 전문적인 내용을 포스팅해볼까 합니다.
IT 쪽을 공부하시지 않으시는 분들은 상당히 재미없을 수 있음을 알려드립니다.

 

1. 인덱스란?

 

모든 DBMS가 제공하는 인덱스는 각양각색이고 알고리즘도 조금씩 다르지만 원하는 데이터를 빨리 찾도록 돕는 게 인덱스입니다.
(아.. 벌써부터 졸음이) ㅋㅋㅋㅋ

 

즉, 책을 예로 들자면 책 맨 앞에 인덱스 페이지가 없다면 어떤 내용이든 한 장씩 훑어가며 찾아야겠죠? 그리고 인덱스 페이지가 적절하지 않아도 한 장씩 훑어가며 찾아야겠죠? 
DBMS에서 사용하는 인덱스도 크게 다르지 않습니다. 

 

2. 인덱스의 구조


 

- 가장 기본적인 B-TREE 구조로 인덱스 탐색 순서는 위 그림과 같이 Root , Branch , Leaf 데이터파일 순서로 진행됩니다.
dept_no = 'd001' and emp_no = '10017'로 검색하면 페이지 4의 Leaf를 탐색 후 데이터를 반환하는 구조입니다.

- emp_no의 경우 dept_no에 대해 의존하고 있습니다. 
즉, emp_no 단독으로는 인덱스를 구성할 수 없기에 인덱스를 사용할 수 없습니다. 2번째는 1번째에 의존도를 3번째는 2번째에 의존도를 가지고 있습니다.

- 인덱스는 많아지면 많아질수록 좋다?? 상황에 따라 다를 수도 있지만 인덱스가 너무 많아지게 되면은 Row 데이터가 등록할 때마다 만들어진 인덱스를 다 추가해야 되기 때문에 성능적인 측면에서 안 좋아질 수 있고 인덱스 역시 위의 그림과 같이 공간을 차지하고 있기 때문에 너무 많은 인덱스는 건강에 해롭습니다. (적당히 뭐든 적당히가 최고죠!!)

 

3. 인덱스 선택


 

- 테이블의 크기가 적은 것(약 5~6 블록 이하)는 인덱스를 만들지 않아도 무방합니다.
하지만, 조인의 연결고리가 되는 칼럼에 인덱스가 없으면 조인의 방향이 달라질 수 있으므로 연결고리가 되는 칼럼은 
인덱스를 생성시키는 것이 좋습니다.

- 같은 값이 적은 칼럼(분포도가 10% 이하인 칼럼) 예) 학교에 학년, 반 이런 거 보다 생년월일, 이름 이런 것들이 분포도가 적음
랜덤 액세스가 빈번한 경우.

- 다른 테이블과 순차적 조인(Nested Join)이 발생되는 Column

- 단순 보관용 이거나 전체 조회 용일 경우에는 인덱스를 생성하지 않는 게 좋습니다. 굳이 전체를 조회하는데 인덱스 공간을 따로 만들어서 보관할 필요가 없기 때문입니다.

 

4. 인덱스 있고 vs 인덱스가 없고 성능 비교


 

- TEST 테이블의 ROW 개수는 21,748,854 개
- 인덱스를 사용해서 SELECT 한 결과입니다.

 

- 인덱스를 사용하지 않은 SELECT 한 결과입니다. (Primary Key 가 잡혀 있어서 정말 정확한 데이터는 아니지만 Scan 계획입니다.)

 

- 결론은 제대로 된 인덱스를 타지 않으면 저렇게 큰 차이가 나며 서버에도 엄청난 부담으로 다가온다는 겁니다.

 

 

5. 결론


 

지루한 내용 끝까지 봐주셔서 감사합니다. 
너무 리뷰 위주로만 한 거 같기에 전문성있는 글도 하나 써봤습니다. ㅎㅎ
졸리시니 다들 커피 한잔 하세요 ^^

댓글

💲 추천 글