Index 기본개념

Index

---

말 그대로 색인이라 하여, Database내의 검색 효율의 속도를 높이기 위한 작업

1. Index 테이블을 따로 해서 만든다
2. Index 테이블에서 where 조건절에 들어갈 rowid값을 추출한다
3. 추출된 값을 다시 찾고자 하는 테이블에서 찾는다. 그러면 딱 그 값들만 찾아가지고 올 수 있다.

Index는 단 데이터를 삽입, 삭제,갱신하는것보다 검색이 훨씬 더 많을때 써야 효율적

왜냐하면, 데이터를 삽입,삭제,갱신하는게 더 많으면, 그만큼 Index 테이블도 영향이 갈것이고, 검색의 효율성이 생각보다 크지 않을수 있기 때문이다.

• 삽입을 하는것은 문제가 좀 덜하다.
• 그러나 삭제, 수정을 할때는 삭제,수정된 row가 바뀌는게 아니라 그냥 메모리에 garbage로 남게된다.

Index는 기본적으로 B+ 트리 형태로 작성이 되어있음

출처 : https://ju-hy.tistory.com/106

왜 Index는 B-Tree나, HashTable을 써서 구성하지 않는지?

→ SQL 질의어에서 부등호 연산이 있기 때문

또한, HashTable은 부등호 연산이 아닌 = 연산 에 특화되어있어서 성능이 떨어짐

→ O(1)이 보장이 안될 수 있기 때문임 (21.10.14 (목) 수정)

주의할 점

---

• 인덱스는 따로 테이블의 형태로 관리가 된다. 자원을 소모한다는 의미. 때문에 무분별한 인덱스의 사용은 성능에 부정적인 영향을 미칠 수 있다.
• 또한 인덱스는 이진트리를 사용하기 때문에 기본적으로 정렬되어 있다. 이로인해 검색과 조회의 속도를 향상시킬 수 있지만 잦은 데이터의 변경(삽입, 수정 삭제)가 된다면 인덱스 데이블을 변경과 정렬에 드는 오버헤드 때문에 오히려 성능 저하가 일어날 수 있다.
  • INSERT : 테이블에는 입력 순서대로 저장되지만, 인덱스 테이블에는 정렬하여 저장하기 때문에 성능 저하 발생
  • DELETE : 테이블에서만 삭제되고 인덱스 테이블에는 남아있어 쿼리 수행 속도 저하
  • UPDATE : 인덱스에는 UPDATE가 없기 때문에 DELETE, INSERT 두 작업 수행하여 부하 발생
• 데이터의 중복이 높은 컬럼(카디널리티가 낮은 컬럼)은 인덱스로 만들어도 무용지물 (예: 성별)
  • 나의 생각 : Where 절로 뽑았을 때 데이터 양이 너무 많으면 인덱스를 쓰는 의미가 없으니까
• 다중 컬럼 인덱싱할 때 카디널리티가 높은 컬럼->낮은 컬럼 순으로 인덱싱해야 효율적