[DB] INDEX?

인덱스?

 

• 인덱스란? 
  • 책의 색인처럼, 검색 속도를 향상하기 위한 자료구조.
  • 해당 TABLE의 컬럼을 색인화(따로 파일로 저장)하여 검색시 해당 TABLE의 레코드를 full scan 하는게 아니라 색인화 되어있는 INDEX 파일을 검색하여 검색속도를 빠르게
• 인덱스 타입 두가지
  • 링크 : https://medium.com/peppermint100/db-%EC%9D%B8%EB%8D%B1%EC%8A%A4-%EC%A2%85%EB%A5%98-clustered-non-clustered-8ad1cffa3126 
  • 클러스터드 인덱스 : 인덱스 키의 순서에 따라 데이터가 정렬되는 저장방식
    • 실제 데이터가 순서대로 정렬되어있어 데이터 빠르게 검색 가능
    • 한 테이블에 하나만 생성 가능
  • Non클러스터드 인덱스 : 인덱스 키 값만 정렬되어있고 실제 데이터는 정렬x
    • 데이터 검색을 하기위해서는 먼저 인덱스를 검색해 실제 데이터의 위치를 파악해야하므로 검색속도 떨어짐
    • 한 테이블에 여러개 생성 가능
• 인덱스 단점
  • 레코드 추가/삭제시, 데이터 변경이 자주 일어나는 경우 인덱스 재작성으로 인한 성능 저하.
  • 인덱스가 DB공간을 차지해 추가적인 공간이 필요
• 사용하면 좋은 경우
  • Where/Join 절에서 자주 사용되는 컬럼
  • 외래키가 사용되는 컬럼
• 사용하면 안좋은 경우
  • Data 중복도가 높은 컬럼
  • DML이 자주 일어나는 컬럼
• DML에 약한 인덱스, INSERT 시 발생하는 INDEX SPLIT 이란?  
  • 인덱스의 BLOCK들이 하나에서 두개로 나누어지는 현상
  • 즉, 인덱스는 데이터가 순서대로 정렬 되어야 하는데, 기존 블록에 여유 공간이 없는 상황에서  그 블록에 새로운 데이터가 입력되어야 할 경우에는 오라클이 기존 블록의 내용 중 일부를 새 블록에다가 기록한 후 기존 블록에 빈 공간을 만들어서 새로운 데이터를 추가하게 됨.
  • 성능면에서 매우 불리한데, 그 이유는
  • 1. 새로운 블록을 할당 받고 key를 옮기는 복잡한 작업을 수행. 모든 수행 과정이 Redo에 기록.. 많은 양의 Redo를 유발함
  • 2. index split이 이루어지는 동안 해당 블록에 대해 키 값이 변경되면 안되므로 DML이 블로킹됨
• DML에 약한 인덱스, DELETE/UPDATE 시
  • DELETE 시 : index에서 데이터가 delete 될 경우 - 데이터가 지워지지 않고, 사용 안 됨 표시만 해 둔다
  • UPDATE 시 : delete와 insert 두 개의 작업이 인덱스에 동시에 일어나 다른 DML보다 더 큰 부하를 줌
• 인덱스 관리 방식
  • B-Tree : 이진 탐색트리와 유사, 루트 - 브랜치 - 리프 구조.
    • 자식 노드를 둘 이상 가질 수 있고 Balanced Tree. 즉, 탐색 연산에 있어 O(log N)의 시간복잡도
    • 모든 노드들에 대해 값을 저장하고 포인터 역할 동반
  • B+Tree : B-Tree 개선한 자료구조.
    • 값을 리프노드에만 저장하고, 리프노트끼리는 리스트로 연결.
    • 때문에 부등호문연산에 효과적
    • 리프 노드를 제외한 노드는 포인터 역할만 수행.
  • Hash Table : 해시 함수를 이용해 키 값을 계산한 뒤, 해당 해시값(hash value)을 인덱스로 이용해 데이터를 저장 및 검색
    • = 등호 연산에 최적화, 정렬되어있지 않기 때문에 부등호 연산에는 적합하지 않음
    • O(1)의 시간 복잡도

 

 

 

 

 

 

 

 

참고 링크 : https://lalwr.blogspot.com/2016/02/db-index.html

DB Index 란?