데이터의 위치를 빠르게 찾아주어 테이블 동작 속도(조회)를 높여주는 자료구조
- Index는 MYI(MySQL Index) 파일에 저장하여 보관
- Index 설정이 없으면, Table Full Scan으로 성능 저하 및 치명적 장애 발생
- Index는 하나 혹은 두개 사양의 Column에 대해 설정 가능
- Index를 많이 설정한다고 검색 속도 향상으로 직결은 x
- Index는 한 Table 당 3~5개 적당
- DB 테이블의 PK 값은 기본적으로 인덱스로 지정되며 queryset을 통해 get이나 filter 메서드 요청시 PK로 조회하면 따른 컬럼으로 조회할 때보다 더 빠름
- 장점
- 조회 속도 상승
- 단점
- 생성, 수정, 삭제 속도가 감소하지만, 수정 및 삭제는 조회를 기반으로 하기에 Index로 보완
- Table Full Scan : Table에 포함된 Record를 처음부터 끝까지 읽어들인다
- Index가 없는 Table의 데이터를 조회할 때 발생
- Table Range Scan : Table의 일부 Record에만 접근하여 읽어들인다
- Index가 설정된 Table의 데이터를 조회할 때 발생
- 높은 카디널리티 (해당 Column의 중복 수치가 낮음)
- ex) 계좌 번호, 주민등록번호 > 성별, 학년
- 낮은 선택도 (한 Column이 갖는 값으로 여러 Row가 찾아지지 않아야 한다)
- 높은 조회 활용도 (해당 Column이 where의 대상 컬럼으로 많이 활용되어야 한다)
- 낮은 수정 빈도 (Index도 Table이기에 Index로 지정된 Column값 변경시 Index Table도 갱신되어야 하기에 차후 수정 가능성이 낮아야 한다)
- 하나의 테이블에 컬럼 수가 너무 많아 full-scan시 성능 저하 발생할 때 사용
- 컬럼수가 적다면, full-scan의 비용이 낮아 index로 처리시 더 많은 비용 발생- 예시
- 배달의 민족에서 현재 주소 및 위치 중심으로 배달 가능 음식점 조회시 DB Index 설정으로 빠른 조회 성능 향상
- 인스타그램에서 팔로잉들의 게시글 조회시엔 잦은 게시글 생성 발생으로 오히려 DB Index 설정시 성능 저하 우려
- DB Table에서 특정 컬럼에 DB Index 설정
- 해당 컬럼과 foreign key가 DB Index 테이블에 저장됨
- DB Index 테이블에서 where에 포함된 값 조회
- 해당 값의 foreign key가 가리키는 DB Table PK 값 불러오기
- 가져온 PK 값으로 기존 테이블에서 값 조회
- B-Tree 기반 자료구조
- 이진트리 검색 (Binary Search)
- O(Log N)의 빠른 조회 성능
- 내부 데이터 정렬 기반으로 생성, 수정, 삭제시마다 정렬이 일어나 성능 저하 우려
- models.py에서 각 모델 정의시 DB Index를 처리할 컬럼의 매개변수에 db_index=True 넣어주기
email = models.EmailField(unique=True, db_index=True)
- 하나의 DB Table에서 여러 필드 한번에 DB Index 처리
class Meta: db_table = 'users' indexes = [ models.Index(fields=['name', 'email']) ] ```
- 검색 및 조회 성능 향상
- 생성, 수정, 삭제의 성능 감소가 있지만 수정 및 삭제는 조회를 필요로 하기에 미미
- Index Table을 위한 추가 공간과 시간(리소스) 필요