인덱스

DB(Table)의 쿼리(검색)속도를 향상시키기 위해 추가적인 쓰기작업과 저장공간을 이용한 자료구조

컬럼들을 쉽게 찾기 위한 일종의 꼬리표를 추가 테이블에 저장하고 관리하는 것인데 추가 테이블을 관리, 이용해야한다는 점때문에 만능이아니며 잘못 사용하면 오히려 악영향을 미칠 수 있다.

인덱스 작업

• 삽입 : 새로운 데이터에 대한 인덱스를 추가

• 삭제 : 삭제하는 데이터의 인덱스를 삭제하는 것이 아닌 사용하지 않음 처리

• 수정 : 기존의 인덱스를 사용하지 않음 처리하고 새로운 인덱스 추가

장점

• 검색 성능 향상

• 성능 향상에 따른 전체적인 시스템 부하 감소

단점

• 추가 저장공간 필요

• 인덱스관리하는 추가 작업 필요

• 수정,삭제는 기본이 삭제가 아닌 사용하지 않음 처리이기 때문에 데이터 크기에 비해 인덱스 테이블 크기가 커져 오히려 성능이 떨어질 수 있다.

구현

일반적으로 HashTable과 B+Tree로 구현되어 있는데 1:1로 매칭되고 해쉬값이 1만달라져도 연관이 없는 아예 다른 값으로 바뀌는 해쉬테이블 같은 경우는 비교 연산(>,< ...)등의 인덱싱에 안좋기 때문에 B+Tree를 주로 사용한다.

MySQL의 InnoDB는 B+Tree기반으로 같은 레벨의 노드들은 더블 링크드 리스트로 구현되어 있다.

사용하기 좋은 테이블

• 컬럼이 충분히 많은 테이블

• 쿼리를 제외한 작업(삽입,수정,삭제)이 자주 발생하지 않는 컬럼

• 자주 검색되는 컬럼에 사용하면 좋다. (select나 where, join 등)

• 카디널리티가 높은 컬럼 (중복도가 낮은 컬럼 == distinct연산 수행했을때 갯수가 많은 컬럼, id같이 중복되지 않는 컬럼이 좋다.)