DB index

  • 테이블 생성 시 하나의 열에 PK 를 지정하면 자동으로 clustered index 가 생성된다.
  • clustered index 가 없는 경우 unique 제약 조건이 있는 테이블을 만들면 자동으로 non clustered index 를 만든다.
  • 기존 테이블에 PK 제약 조건을 적용하려 하거나 테이블에 clustered index 가 이미 있으면 non-clustered index 를 사용하여 PK 를 적용한다.

1. clustered index

출처 - https://velog.io/@gillog/SQL-Clustered-Index-Non-Clustered-Index
  • 루트 페이지와 리프 페이지로 구성되며, 리프 페이지는 데이터 그 자체이다. 즉, Index 자체에 데이터가 포함되어 있다.
  • 한 테이블에 하나 씩만 설정할 수 있다.
  • 물리적으로 정렬되어 순서대로 저장된다. 중간에 값이 insert 되면 그 뒤로 모든 PK 값을 다시 수정해야 한다.
  • 범위 검색에 좋다.
  • 존재하는 PK 사이에 insert 할 경우 성능에 문제가 생기기 때문에 보통 auto_increase 옵션을 사용해 설정한다.

2. non clustered index

출처 - https://velog.io/@gillog/SQL-Clustered-Index-Non-Clustered-Index
  • 물리적으로 데이터를 배열하지 않은 상태이다.
  • 순서에 상관 없다.
  • 한 테이블에 여러 개 설정할 수 있다.
  • index 정보를 저장하기 위해 약 10% 추가 저장공간이 필요하다.
  • insert 시 index b-tree 를 구성하는 추가 작업이 필요하다.
  • 상대적인 중복의 정도를 나타내는 카디널리티를 고려해 설정해야 한다.

3. clustered, non clustered index 통합

출처 - https://velog.io/@gillog/SQL-Clustered-Index-Non-Clustered-Index

4. index 의 구조와 원리

  • select 가 많은 테이블에 사용하면 좋다.
  • insert, delete, update 가 많은 타입에는 좋지 않다.
  • insert 시 leaf 노드에서 뒤에 있는 데이터를 모두 미뤄줘야 하고 페이지가 꽉찬 경우
    새로운 페이지를 만들고 index b-tree 의 밸런스를 다시 잡아야 하므로 오래 걸린다.
  • delete 시 index b-tree 에서 실제 삭제하지 않고 마스킹만 하기 때문에 공간 손해가 발생한다.
  • update 시 index b-tree 에서 삭제 후 다시 insert 하기 때문에 작업이 오래 걸린다.