클러스터링 인덱스
- InnoDB 스토리지 엔진만 지원
- 프라이머리 키에 적용되는 내용
- 프라이머리 키 값에 의해 레코드 저장 위치가 결정
프라이머리 키 기반의 검색이 매우 빠르지만 레코드의 저장이나 프라이머리 키의 변경이 상대적으로 느리다
B-Tree 와 비슷하지만 리프노드에 레코드의 모든 컬럼이 같이 저장돼 있음
InnoDB 스토리지 엔진 우선순위 프라이머리 키
- 프라이머리 키가 있으면 기본적으로 프라이머리 키를 클러스트링 키로 선택
- NOT NULL 옵션의 유니크 인덱스(Unique index) 중에서 첫번째 인덱스를 클러스트링 키로 선택
- 자동으로 유니크한 값을 가지도록 증가되는 컬럼을 내부적으로 추가한 후, 클러스트링 키로 선택
적절한 키를 찾지 못하는 경우 내부적으로 레코드의 일련번호 컬럼을 생성, 노출되지 않으며 명시적으로 사용할 수 없다. InnoDB 테이블에서 클러스트링 인덱스는 테이블당 단 하나만 가질 수 있는 엄청난 혜택이므로 가능하다면 프라이머리 키를 명시적으로 생성하자.
세컨더리 인덱스에 미치는 영향
- MyISAM : 세컨더리 인덱스가 가지고 있은 레코드 주소로 검색
- InnoDB : 세컨더리 인덱스로 프라이머리 키 검색 -> 프라이머리키가 가자고 있는 레코드 주소로 검색
클러스트링 인덱스 장점
- 프라이머리 키(클러스터링 키)로 검색할 때 처리 성능이 매우 빠름(특히, 프라이머리 키를 범위 검색하는 경우 매우 빠름)
- 테이블의 모든 세컨더리 인덱스가 프라이머리 키를 가지고 있기 때문에 인덱스만으로 처리될 수 있는 경우가 많음 (이를 커버링 인덱스라고 한다)
클러스트링 인덱스 단점
- 테이블의 모든 세컨더리 인덱스가 클러스트링 키를 갖기 때문에 클러스터링 키 값의 크기가 클 경우 전체적으로 인덱스의 크기가 커짐
- 세컨더리 인덱스를 통해 검색할 때 프라이머리 키로 다시 한번 검색해야 하므로 처리 성능이 느림
- INSERT할 대 프라이머리 키에 의해 레코드의 저장 위치가 결정되기 때문에 처리 성능이 느림
- 프라이머리 키를 변경할 때 레코드를 DELETE하고 INSERT하는 작업이 필요하기 때문에 처리 성능이 느림
클러스터링 테이블 사용 시 주의사항
1. 클러스터링 인덱스 키의 크키
모든 세컨더리 인덱스가 프라이머리 키값을 포함하기 때문에 프라이머리 키가 커지면 세컨더리 인덱스도 자동으로 커진다. 프라이머리 키가 커지면 세컨더리 인덱스 크기는 급격하게 증가 프라이머리 키를 신중하게 선택
2. 프라이머리 키는 AUTO-INCREMENT 보다는 업무적인 컬럼으로 생성
프라이머리 키로 검색하는 경우 (특히 범위로 많은 레코드를 검색하는 경우) 매우 빠르게 처리됨
3. 프라이머리 키는 반드시 명시할 것
만들지 않는다면 자동으로 추가됨 가능하면 AUTO_INCREMENT 컬럼을 이용
4. AUTO-INCREMENT 컬럼을 인조 식별자로 사용할 경우
세컨더리 인덱스도 필요하고 프라이머리 키의 크기도 길다면 AUTO_INCREMENT 컬럼을 추가하고, 이를 프라이머리 키로 설정 이를 인조 식별자(Surrogate key)라고 함, 로그 테이블과 같이 조회보다는 INSERT 위주의 테이블들은 AUTO_INCREMENT를 이용한 인조 식별자를 프라이머리 키로 설정하는 것이 성능 향상에 도움이 됨