인덱스
데이터가 정렬돼있으면 원하는 데이터를 더 빠르게 찾을 수 있다라는 특성을 적용한 개념
Clustered 인덱스
테이블 자체를 특정 순서로 저장하는 인덱스
- 조회 속도가 굉장히 빠르다. (이진탐색을 사용할 수 있기 때문)
- 인덱스를 하나밖에 못만든다.
| name | age | |
|---|---|---|
| a@mail.com | 박자바 | 50 |
| b@mail.com | 김코딩 | 20 |
| 핳@mail.com | 이리액트 | 30 |
| 가@mail.com | 고파이썬 | 10 |
만약 email 컬럼에 email을 알파벳 순으로 정렬해 저장하면 name이나 age컬럼은 정렬할 수 없기 때문에 인덱스가 email 하나밖에 존재할 수 없다. 이에 따라 name이나 age를 조회하기 위해선 선형탐색을 해야한다. 또한 email에 한글이 들어가있으면 email이 인덱스임에도 불구하고 선형탐색으로 찾아야한다.
Non-clustered 인덱스
테이블 자체는 그대로 놔두고 다른 곳에 순서를 저장
- 인덱스를 모든 컬럼에 대해서 만들 수 있다.
- 데이터가 분산되어있기 때문에 clustered 인덱스 보다는 조금 느리다.
email_table
| name | age | |
|---|---|---|
| b@mail.com | 김코딩 | 20 |
| a@mail.com | 박자바 | 50 |
email_index table
| memory_addess | |
|---|---|
| a@mail.com | 1010 |
| b@mail.com | 1080 |
email 테이블은 그대로 두고 email 메모리 주소만 저장하는 테이블을 별도로 만들어 email을 정렬하는 방식이다. 이에 따라 email 뿐만 아니라 나머지 name, age도 각 컬럼별로 인덱스 테이블를 만들어 저장할 수 있다.
Composite 인덱스
하나의 컬럼이 아니라 여러개의 컬럼에 대해 합쳐진 인덱스
위의 예시를 기반으로 만약 email과 name을 함께 조회해야 하는데 email과 name 인덱스 테이블이 각각 존재한다고 가정하자. 그러면 결국 하나의 인덱스 테이블을 이진 탐색하여 해당 주소로 들어가 나머지 하나를 선형탐색으로 조회하는 수밖에 없다. 각
컬럼별로 인덱스 테이블이 있어도 결국 선형탐색을 할 수 밖에 없는 것이다.
이처럼 두개, 또는 그 이상의 조건을 사용해서 조회를 많이 해야하는 경우 컬럼 하나가 아니라 여러개에 대해서 인덱스를 만들 수 있다.
| brand | type | color | memory_address |
|---|---|---|---|
| 구찌 | 긴팔 | 노랑 | 1040 |
| - | - | 파랑 | 1020 |
| - | 나시 | 검정 | 1030 |
| - | 흰색 | 1060 | |
| 나이키 | 긴팔 | 검정 | 1090 |
| - | - | 흰색 | 1230 |
위의 인덱스 테이블을 사용한다면 brand와 type을 기준으로 조회할 때 모두 이진 탐색을 사용할 수 있다. type과 color을 기준으로 조회할 때에도 모두 이진 탐색을 사용할 수 있다. 그러나 이 테이블에서도 만약 brand와 color를 기준으로 조회한다면 이 경우에도 이진탐색으로 brand를 찾고 선형탐색으로 color를 찾아야한다. color는 brand전체에 대해서는 정렬되어있지 않기 때문이다.
따라서 여러 컬럼에 대한 인덱스를 사용할 때에는 항상 가장 왼쪽 조건으로 가장 많이 사용하는 컬럼을 사용하고 오른쪽으로 갈수록 조건으로 덜 사용하는 컬럼을 사용해야 한다.
인덱스의 단점 (non-clustered 인덱스)
- 용량을 많이 차지한다. 이로인해 성능이 저하되고 속도가 느려질 수 있다.
- 조회는 빨라지지만 삽입, 업데이트, 삭제는 오히려 느리다.
데이터를 수정할 때 하나의 로우 값을 바꾸면 해당 컬럼이 포함된 모든 인덱스를 수정해야한다. 만약 이메일 테이블을 수정하면 이메일 인덱스 테이블의 이메일도 수정해야하고 이로 인해 재정렬을 해야한다.
따라서 인덱스를 추가할 때에는 관련 컬럼들이 얼마나 자주 삽입, 업데이트, 삭제되는지 파악해야한다. 연산이 많이 필요한 컬럼들에는 인덱스가 오히려 역효과는 낳기 때문이다.
인덱스 추가 기본 원칙
- 모든 primary key에 대해서 인덱스를 만들어준다.
- 모든 foreign key에 대해서 인덱스를 만들어준다.
- 특정 조회 쿼리가 너무 느려지거나, 느려질게 확실한 경우 조회에 사용되는 컬럼들에 대해서 인덱스를 만들어준다.
