인덱스란?
인덱스를 설명할 때 보통 책에 있는 색인을 예시로 설명을 한다
어떤 내용이 어디 있는지 확인하기 쉽지 않으니
초반부에 찾아보기 쉽게 특정 페이지의 위치를 표시해두는데
인덱스도 그러한 역할을 한다
만약 A테이블과 B테이블을 Join 하여 조회한다고 했을 때
DB 에서는 연결된 모든 레코드를 Full Scan 한다
조회 수 : R(A) * R(B)
당연히 데이터가 많으면 많을수록 그만큼 조회 해야 하는 데이터도 늘어나기에
성능적으로 문제가 생기거나 잘못하면 한번에 너무 큰 데이터를 불러와
터질수도 있는 상황이 발생한다.
인덱스는 색인을 붙여 Full Scan 을 하지 않고 빠르게 원하는 데이터를 찾게 해주는 도구이다.
B+Tree
대부분의 인덱스는 B+Tree 알고리즘을 이용해 데이터를 탐색한다.
(이외에 Hash, Bitmap 구조등을 사용하기도 한다)
크게 3가지 노드로 나뉜다.
- 루트 노드(Root Node) : 최상위 노드로 여러개의 key 를 저장
- 중간 노드(Internal Node) : 경로를 안내하는 역할
- 리프 노드(Leaf Node) : 실제 데이터를 저장하며 연결 리스트(Linked List)처럼 연결됨
동작 방식은 간단하게 다음과 같다.
- 상위 노드보다 작으면 왼쪽 크면 오른쪽으로 이동 (Key 기준)
- 반복하여 쭉쭉 내려가 해당하는 Key 를 발견하면 data 반환
- 맨밑의 리프 노드는 연결리스트로 이어져 있어 인접한 Key 로 이동이 가능 (더욱 효율적 탐색이 가능)
만약 범위탐색의 경우 3번이 매우 큰 역할을 하는데
B+Tree방식으로 구간의 시작점을 빠르게 찾고
LinkedList로 인접한 노드를 순차적으로 빠르게 접근할 수 있어
매우 효율적인 탐색이 가능하다.
그렇다고 마냥 좋은 것이 아닌 인덱스에도 단점이 존재하는데
인덱스는 쓰기 작업을 희생시켜 읽기 작업을 최적화하는 도구이다
인덱스가 많으면 데이터 변경 시 인덱스도 업데이트해야 하므로 오버헤드가 발생하고
인덱스를 저장하기 위한 추가적인 공간도 요구해
인덱스가 많아질수록 비용이 증가한다.
따라서 인덱스의 사용방법을 정리하자면
쓰기 작업이 덜 일어나고 읽기 작업이 많이 일어나는 곳에 신중하게 걸자
라고 할 수 있겠다.
인덱스를 주로 걸어야 하는 상황
- WHERE 절에 자주 사용되는 열
- SELECT 절에 자주 등장하는 열
- JOIN 절에 자주 사용되는 열
- ORDER BY / GROUP BY → 정렬 및 그룹화가 자주 이루어지는 경우
주의할 점
- 단일 테이블에 인덱스가 너무 많으면 오히려 악영향 (테이블당 4~5개 권장)
- 검색할 데이터가 전체 데이터의 20% 이상이면 MySQL 에서 인덱스를 사용하지 않음
- 자주 사용하지 않은 인덱스는 제거하자
다음에는 복합 인덱스에 대한 글을 정리해보도록 하겠다
