DB - Index

Index

- DB 테이블에 대한 동작의 속도를 높여주기 위한 자료구조.(출처 : wikipedia) 

 

DB 테이블은 열을 가리키는 속성(Attribute)들과 행을 가리키는 튜플(Tuple)로 구성되는데,

테이블 전체를 하나의 '책'으로, 하나의 행을 '각 페이지(안의 내용)'라고 비유한다.

이 때, 책에서 특정 내용을 찾기 위한 방법이 무엇일지 생각해보자.

 

예를 들어, 데이터베이스 책에서 index에 대한 내용을 찾고 싶다면, 

책의 첫 페이지부터 마지막 페이지까지 다 살펴보지 않을 것이다.

책의 앞부분에는 '목차'가 있기 때문에 'Index'라는 내용이 몇번째 페이지에 있는지 바로 알 수 있고,

우리는 바로 해당 페이지로 넘어가서 index에 대한 내용을 볼 수 있다.

데이터베이스에서 말하는 Index가 바로 책의 목차와 같다.

 

• 인덱스는 한 컬럼에 하나만 사용 가능
• 기본키는 디폴트로 인덱스 생성
• 인덱스 적용 컬럼 고려 기준
  
  1. 중복성 : 컬럼이 가지고 있는 값들의 중복 정도가 낮은 컬럼에 사용(카디널리티가 높은 컬럼)
  2. 활용성 : WHERE절, ORDER BY절, JOIN절에서 참조 빈도가 높은 컬럼
  3. 테이블 수정 빈도 : 위의 기준을 만족하는 컬럼에 인덱스를 사용하더라도, 테이블의 데이터가 자주 변한다면 사용을 고려해야 한다.

 

 

Index 장점

• 인덱스를 사용하면 효율적으로 데이터를 조회(SELECT)할 수 있다.
  
  • 다만, 모든 경우에 인덱스가 조회 성능을 향상시키는 것은 아니다.
  • 인덱스가 '잘 사용된' 컬럼을 WHERE 절에서 참조하거나, sorting 조회할 때 큰 효율을 볼 수 있다.

 

 

Index 단점

• 잘 사용하지 않으면 오히려 비효율을 초래한다.
• 인덱스 테이블을 저장하기 위한 추가 공간 필요(본 테이블의 약 10%를 요구)
• DML 중, (INSERT, DELETE, UPDATE) 시 인덱스 구조를 정리하기 위한 작업이 추가로 진행된다.
  • 그렇다고 해서, 무조건 DML에 악영향을 미치는 것은 아니다. DELETE, UPDATE시 해당하는 데이터를 찾기 위해 결국 데이터를 조회해야 하는데, 이 때는 인덱스의 조회 성능 향상의 이점이 있다. 하지만 인덱스의 사용이 DELETE, UPDATE에 대한 전반적인 성능을 높이는 경우는 드물다고 한다.

 

B+ Tree

- 인덱스를 저장하는 대표적인 자료구조이다.

출처: https://blog.jcole.us/2013/01/10/btree-index-structures-in-innodb/

• 모든 key : value가 리프노드에 존재한다.
• 리프노드들이 더블 링크드 리스트로 구성된다.
  • 리프노드에서 선형 검색 가능!

 

 

 

 

 

 

출처

mangkyu.tistory.com/96

yurimkoo.github.io/db/2020/03/14/db-index.html

itholic.github.io/database-index/

www.gurubee.net/lecture/2926

velog.io/@gillog/SQL-Index%EC%9D%B8%EB%8D%B1%EC%8A%A4