SQL을 사용하다 보면, Index에 관해서 들어본 적이 있을 것이다.
과연 Index란 무엇이고 왜 사용해야 하는 것일까?

먼저, RDBMS에서 검색(조회) 성능을 높이기 위해 사용하는 개념이다.
요즘은 잘 안쓰지만, 예전에 사용하던 전화번호부를 생각해보자.
우리가 박수민 이라는 이름을 찾으려면 ㅂ을 먼저 찾을 것이다.
바로 저 ㅂ이 색인, 즉 Index가 되는 것이다.

보통 SQL 서버는 Data를 저장을 하게 되면, Heap 영역에 저장을 하는데
이 때, 아무 순서 없이 무작위로 저장을 하게 된다.
즉, Query를 날려 어떤 Data를 찾으려면 Table(Full) Scan 을 해야 한다.

하지만, Index가 있으면 해당 Index에 해당하는 부분만 찾으면 된다.
삽입 / 수정 / 삭제에 대한 성능은 저하될 수 있지만 조회 성능이 매우 향상된다!

왜 사용하는가?

Index의 가장 큰 특징은, Data들이 정렬됨에 있다.
이 매우 유용한 특징으로 인해 조회에 있어 다음과 같은 장점들을 갖는다.

  • WHERE 절(조건 검색)의 효율성
  • ORDER BY 정렬의 효율성
  • MIN(), MAX() 함수의 효율성

하지만 어떤 유용한 장비라도 단점은 있기 마련이다.

  • 추가 공간의 필요성
    • Talbe 공간의 30%를 Index에 할당할 정도로 공간이 필요하다.
  • 삽입, 수정, 삭제에 대한 부하
    • Index로 인해 삽입, 수정, 삭제가 2번 발생하게 된다.
    • 이는 너무 많은 Index가 존재할 경우 큰 부하를 일으킨다.
    • 따라서, Index는 한 Table 당 3~5개 정도가 적당하다.
  • Index를 주기적으로 관리할 인력이 필요하다.

하지만, 단점들이 더 많음에도 왜 Index를 사용하는 것일까?
현재 일반적인 OLTP 시스템에서는 조회 업무가 90% 이상을 차지하기 때문이다.
이러한 조회 속도의 향상은, 업무 효율을 높이는 데에 매우 큰 기여를 하게 될 것이다.

따라서, 아래와 같은 경우 Index를 반드시 사용한다.

  • Table의 규모가 작지 않다.
  • 삽입, 삭제, 수정이 자주 발생하지 않는다.
  • JOIN, WHERE, ORDER BY가 자주 발생한다.
  • Data의 중복도가 낮다.

Index의 구조

Index는 기본적으로 B-Tree(Balanced Tree) 구조를 갖는다.
그 중에서도 파생된 B* Tree와 B+ Tree`의 구조를 갖는다.
대부분의 DBMS가 이 형태를 사용하며, 특히 Oracle에서 중점적으로 사용한다.

그런데, 흔히 알고 있는 검색 Table인 Hash Table은 O(1)의 낮은 복잡도를 갖는다.
그럼 왜 Hash Table을 쓰지 않고, B+ Tree 구조를 사용하는가?
Hash Table의 원리를 알고 있다면, 이해가 가능하다.

  • Hash Table
    • Hash Function을 통해 특정 Hash 값(고정 값)을 내뱉는다.
    • 해당 Hash 값을 통해 Hash Table에 적힌 Index를 보고 찾아간다.
    • 즉 = 연산자에 대한 Data 검색이 O(1) 이라는 의미이다.

하지만 우리가 Query를 짜면, 분명 = 뿐만 아니라 >= 등 범위 연산자 들어간다.
과연 그럴 때에도 Hash Table이 더 우세하다고 말할 수 있을까?

btree

B-Tree 는 위 사진 처럼 하나의 Node에 여러 Data를 저장하는 Tree이다.
위와 같이 Root - Branch - Leaf의 형태를 갖고 있다.
Node 내의 Data들은 항상 정렬되며, 해당 Data 사이의 범위를 이용해 자식 노드를 가진다.
Node 내의 Data 수가 N개이면, 자식 Node의 수는 N+1개가 된다.

Index의 종류

  • Cluster Index
  • Non-Cluster Index
    • Single Index
    • Composite Index
    • Covered Index
  • Unique Index : 유일한 값을 갖는 인덱스이다.
    • UNIQUE Constraint와는 다르게 NULL을 허용하지 않는다.