소개

클러스터란 여러 개를 하나로 묶는다는 의미로 주로 사용되는데, 지금 설명하는 인덱스의 클러스터링도 그 의미를 크게 벗어나지 않는다. InnoDB와 TokuDB 스토리지 엔진에서만 지원하며, 나머지 스토리지엔진에서는 지원되지 않는다.

5.9.1 클러스터링 인덱스

클러스터링 인덱스는 테이블의 프라이머리 키에 대해서만 적용되는 내용이다. 즉 프라이머리 키값이 비슷한 레코드끼리 묶어서 저장하는 것을 클러스터링 인덱스라고 표현한다. 여기서 중요한것은 프라이머리 키값에 의해 레코드의 저장위치가 결정된다는 것이다. 또한 프라이머리 키값이 변경된다면 그 레코드의 물리적 저장위치가 바뀌어야 한다는 것을 의미한다. 프라이머리 키값에 의해 레코드의 저장위치가 결정되므로 사실 인덱스 알고리즘이라기 보다 테이블 레코드의 저장방식이라고 볼 수 있다. 프라이머리 키를 클러스터 키라고도 표현한다. 일반적으로 InnoDB 와 같이 항상 클러스터링 인덱스로 저장되는 테이블은 프라이머리 키 기반의 검색이 매우 빠르며, 대신 레코드의 저장이나 프라이머리 키의 변경이 상대적으로 느릴 수 밖에 없다. B-Tree와는 달리 클러스터링 인덱스의 리프 노드에는 모든 칼럼이 같이 저장된다. 즉 클러스터링 테이블은 그 자체가 한의 거대한 인덱스 구조로 관리되는 것이다. 프라이nu머리 키가 없는 InnoDB 테이블은 어떻게 클러스터 테이블을 구성될까.

  1. 프라이머리 키가 있으면 기본적으로 프라이머리 키를 클러스터 키로 선택
  2. NOT NULL 옵션의 유니크 인덱스 중에 첫번째 인덱스를 클러스터 키로 선택
  3. 자동으로 유니크한 값을 가지도록 증가되는 칼럼을 내부적으로 추가한 후, 클러스터 키러 선택

5.9.2 보조 인덱스에 미치는 영향

MyISAM 이나 MEMORY 테이블과 같은 클러스터링 되지 않는 테이블은 INSERT 될때 한번 저장된 공간에서 절대 이동하지 않는다. 보조 인덱스나 프라이머리 키는 ROWID 를 이용해 실제 데이터 레코드를 찾아온다. 그래서 MyISAM 이나 MEMORY 테이블은 프라이머리 키나 보조 인덱스가 동일하다. InnoDB 테이블의 모든 보조 인덱스는 해당 레코드가 저장된 주소가 아니라 프라이머리 키값을 저장하도록 구현돼 있다.

5.9.3 클러스터 인덱스의 장점과 단점

  • 장점
    • 프라이머리키로 검색할 때 성능이 매우 빠름
    • 테이블의 모든 보조 인덱스가 프라이머리 키를 가지고 있기 때문에 인덱스만으로 처리될 수 있는 경우가 많음
  • 단점
    • 테이블의 모든 보조 인덱스가 클러스 키를 갖기 때문에 클러스터 키값의 크기가 클 경우 전체적으로 인덱스의 크기가 커짐
    • 보조 인덱스를 통해 검색할 때 프라이머리키로 다시 한번 검색해야 하므로 처리 성능이 조금 느림
    • Insert 할 때 프라이머리 키에 의해 레코드의 저장위치가 결정되기 때문에 처리 성능이 느림
    • 프라이머리 키를 변경할 때 레코드를 DELETE하고 INSERT 하는 작업이 필요하기 때문에 처리 성능이 느림

5.9.4 클러스터 테이블 사용시 주의사항

  • 클러스터 인덱스 키의 크기 : 클러스터 테이블의 경우 모든 보조 인덱스가 프라이머리 키 값을 포함한다. 그래서 프라이머리 키의 크기가 커지면 보조 인덱스도 자동으로 크기가 커진다.
  • 프라이머리 키는 AUTI-INCREMENT 보다는 업무적인 칼럼으로 생성할 것(가능한 경우)
  • 프라이머리 키는 반드시 명시할 것
  • AUTO-INCREMENT 칼럼을 인조 식별자로 사용할 경우 : 여러 개의 컬럼이 복합으로 프라이머리 키가 만들어지는 경우 프라이머리 키의 크기가 길어질 때가 가끔있다. 하지만 프라이머리 키의 크기가 길어도 보조 인덱스가 필요치 않다면 그대로 프라이머리 키를 사용하는 것이 좋다.