[Real Mysql 8.0] 클러스터링 인덱스

1. 프라이머리 키가 데이터 레코드의 저장에 미치는 영향

 클러스터링 인덱스는 테이블의 프라이머리 키에 대해서만 적용되는 내용이다. 즉, 프라이머리 키 값이 비슷한 레코드끼리 묶어서 저장하는 것을 클러스터링 인덱스라고 표현한다.

 일반적으로 클러스터링 인덱스로 저장되는 테이블은 프라이머리 키 기반으로 검색이 매우 빠르며, 대신 레코드의 저장이나 프라이머리 키의 변경이 상대적으로 느리다.

  B-Tree인덱스도 인덱스 키 값으로 이미 정렬되어 이것도 클러스터링 됐다고 할 수 있지만, 테이블의 레코드가 프라이머리 키 값으로 정렬되어 저장된 경우에만 "클러스터링 인덱스" 또는 "클러스터링 테이블"이라고 부른다.

 클러스터링 인덱스 구조를 보면 클러스터링 테이블의 구조 자체는 일반 B-Tree와 비슷하다. 하지만 세컨더리 인덱스를 위한 B-Tree의 리프노드와는 달리 클러스터링 인덱스의 리프 노드에는 레코드의 모든 칼럼이 같이 저장돼 있다.

그러면, 프라이머리 키가 없는 테이블은 어떻게 클러스터링 테이블로 저장될까?

1. 프라이머리 키가 있으면 기본적으로 프라이머리 키를 클러스터 키로 선택
2. NOT NULL 옵션의 유니크 인덱스 중에서 첫 번째 인덱스를 클러스터링 키로 선택
3. 자동으로 유니크한 값을 가지도록 증가되는 컬럼을 내부적으로 추가한 후, 클러스터링 키로 선택
   • 이렇게 자동으로 추가된 프라이머리 키는 사용자에게 노출되지 않으며, 쿼리 문장에 명시적으로 사용할 수 없다. 그러므로 프라이머리 키를 명시적으로 생성해주는게 좋다.

2. 세컨더리 인덱스에 미치는 영향

 세컨더리 인덱스가 실제 레코드가 저장된 주소를 가지고 있다면 어떻게 될까? 클러스터링 키 값이 변경될 때마다 데이터 레코드의 주소가 변경되고 그때마다 해당 테이블의 모든 인덱스에 저장된 주솟값을 변경해야 한다. 이런 오버헤드를 제거하기 위해 모든 세컨더리 인덱스는 레코드가 저장된 주소가 아니라 프라이머리 키 값을 저장하도록 구현돼 있다.

 

3. 추론

 Mysql의 InnoDB엔진에서의 모든 B-Tree인덱스는 세컨더리 인덱스이다.