인덱스란?
테이블 안에 찾고자 하는 데이터를 빠르게 찾을 수 있는 기능을 한다.
보통 B-트리 라는 자료구조로 이루어져있음
(이진 트리를 확장해 하나의 노드가 가질 수 있는 자식 노드의 최대 숫자가 2보다 큰 트리 구조이다. https://ko.wikipedia.org/wiki/B_%ED%8A%B8%EB%A6%AC)
인덱스가 효율적인 이유
- 효율적인 단계를 거쳐 모든 요소에 접근할 수 있는 균형잡힌 트리 구조
- 트리 깊이의 대수 확장성
대수확장성이란?
트리 깊이가 리프 노드 수에 비해 매우 느리게 성장, 인덱스 깊이가 1씩 증가할 때마다 최대 인덱스 항목 수 4배 증가
ex) 트리 깊이 3: 인덱스 항목 수64 / 트리 깊이 5 : 인덱스 항목 수 1024
인덱스 만드는 방법
MySQL
클러스터형 인덱스와 세컨더리 인덱스가 있다.
클러스터형 인덱스는 테이블당 하나를 설정할 수 있다. primary key 옵션으로 기본키를 만들면 클러스터형 인덱스를 생성할 수 있다.
기본키가 아니어도 unique not null 옵션을 붙이면 클러스터형 인덱스로 만들 수 있다.
create index 명령어를 기반으로 세컨더리 인덱스를 만들 수 있다.
인덱스를 하나만 만들 것이라면 클러스터형이 성능이 더 좋다.
세컨더리는 인덱스는 보조 인덱스로, 여러 필드값을 기반으로 쿼리를 많이 보낼 때 생성하는 인덱스이다.
ex) age라는 하나의 필드만으로 쿼리를 보내면 클러스터형 필요, 그러나 age, name, email 등 다양한 필드를 기반으로 쿼리를 보낼 땐 세컨더리 인덱스 사용
MongoDB
도큐먼트를 만들면 자동으로 ObjectID가 형성되며, 해당 키가 기본키로 설정된다.
세컨더리 키도 부가적으로 설정해서 기본키와 세컨더리키를 같이 쓰는 복합 인덱스를 설정할 수 있다.
인덱스 최적화
1. 인덱스는 비용이다.
인덱스는 인덱스 리스트, 컬렉션 순으로 탐색하기에 관련 읽기 비용이 든다.
또한 컬렉션이 수정되면 인덱스도 수정되어야한다. 이 때 B-트리를 조절하는 비용과 데이터를 효율적으로 조회할 수 있도록 분산시키는 추가 비용도 든다.
따라서 필드에 인덱스를 무작정 다 설정하는것은 좋지 않다.
또한 컬렉션에서 가져와야하는 양이 많을수록 인덱스는 비효율적이다.
2. 항상 테스팅하라
인덱스 최적화 기법은 서비스 특징에 따라 다르다. 서비스마다 사용하는 객체의 깊이, 테이블 양 등이 다르기 문이다.
따라서 항상 테스팅 하며 걸리는 시간을 최소화 해야한다.
explain() 함수를 통해 테스팅을 한다.
EXPLAIN
SELECT * FROM t1
JOIN t2 ON t1.c1 = t2.c1;3. 복합 인덱스는 같음, 정렬, 다중 값, 카티널리티 순이다.
인덱스는 생성 순서에 다라 성능이 달라진다.
같음, 정렬, 다중 값, 카디널리티 순으로 생성해야한다.
1. ==이나 equal이라는 쿼리가 있으면 제일 먼저 인덱스로 설정
2. 정렬에 쓰는 필드라면 그다음 인덱스로 설정
3. 쿼리 자체가 > or < 등 많은 값을 출력해야하는 쿼리에 쓰는 필드라면 나중에 인덱스 설정
4. 유니크한 값의 정도를 카디널리티라고 하며, 이 카디널리티가 높은 순서를 기반으로 인덱스를 생성해야한다.
ex) age와 email 중 email이 카디널리티가 높으므로 email 필드에 대한 인덱스 먼저 생성
