InnoDB Clustering Index

클러스터링 인덱스

프라이머리 키값이 비슷한 레코드끼리 묶어서 저장하는 구조

• PK에 의해 레코드의 저장 위치가 결정된다.
• PK값이 변경되면 레코드의 물리적인 저장 위치가 변경된다.
• PK기반의 검색이 매우 빠르다
• 레코드의 저장, PK의 변경이 상대적으로 느리다.

B Tree의 리프 노드와는 달리, 클러스터링 인덱스의 리프 노드에는 레코드의 모든 칼럼이 같이 저장되어 있다.

• 테이블 자체가 하나의 거대한 인덱스 구조

프라이머리 키가 없는 테이블

다음 우선순위대로 PK를 대체할 칼럼을 선택한다.

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

클러스터링 인덱스는 엄청난 혜택이므로 가능하다면 PK를 명시하자.

보조 인덱스에 미치는 영향

InnoDB 테이블의 모든 보조 인덱스는 해당 레코드가 저장된 주소가 아닌 PK값을 저장하도록 구현되어 있다.

• 인덱스를 검색해 레코드의 PK값을 확인한 뒤
• PK값을 이용해 테이블을 한번 더 검색한 후 최종 레코드를 가져온다.

클러스터 인덱스의 장단점

장점

• PK로 검색할 때 처리 성능이 매우 빠름( 특히, PK를 범위 검색하는 경우 매우 빠름 )
• 테이블의 모든 보조 인덱스가 PK를 가지고 있기 때문에 인덱스만으로 처리될 수 있는 경우가 많음 (covering index)

단점

• 모든 보조 인덱스가 클러스터 키를 가지므로 클러스터 키값의 크기가 클 경우 전체적으로 인덱스의 크기가 커짐
• 보조 인덱스를 통해 검색할 때 PK로 다시한번 검색해야 하므로 성능이 약간 느림
• INSERT할 때 PK에 의해 레코드의 저장 위치가 결정되기 때문에 처리 성능이 느림
• PK를 변경할 때 레코드를 DELETE하고 INSERT하는 작업이 필요해서 성능이 느림

Reference

mysql 공식문서