프라이머리 키 값이 비슷한 레코드 끼리 묶어서 저장하는 것을 클러스터링 인덱스라 표현한다. 프라이머리 키 값에 의해 레코드의 저장 위치가 결정된다. 프라이머리 키가 변경되면 그 레코드의 물리적인 저장 위치가 변경된다.
프라이머리 키 값으로 클러스터링된 테이블은 프라이머리 키 값 자체에 대한 의존도가 상당하기 때문에 신중히 결정해야 한다.
일반적으로 InnoDB와 같이 항상 클러스터링 인덱스로 저장되는 테이블은 프라이머리 키 기반의 검색이 매우 빠르며, 레코드의 저장이나 프라이머리 키의 변경이 상대적으로 느리다.
만약 프라이머리 키가 없는 InnoDB의 경우 어떻게 클러스터링 테이블을 구성할까? 프라이머리 키가 없는 경우 InnoDB 스토리지 엔진이 아래와 같은 우선순위로 프라이머리 키를 대체할 컬럼을 선택한다.
프라이머리 키가 있으면 기본적으로 프라이머리 키를 클러스터링 키로 선택한다.
NOT NULL 옵션의 유니크 인덱스(UNIQUE INDEX) 중에 첫 번째 인덱스를 클러스터링 키로 선택한다.
자동으로 유니크한 값을 가지도록 증가되는 칼럼을 내부적으로 추가한 후, 클러스터링 키로 선택한다.
세컨더리 인덱스에 미치는 영향
MyISAM 테이블이나 Memory 테이블에는 프라이머리 키와 세컨더리 인덱스의 구조적 차이가 존재하지 않는다.
만약 InnoDB 테이블에서 세컨더리 인덱스가 실제 레코드가 저장된 주소를 가지고 있다면 어떻게 할까? 클러스터링 키 값이 변경될 때마다 데이터 레코드의 주소가 변경되고 그때마다 해당 테이블의 모든 인덱스에 저장된 주소값을 변경해야 한다. 이러한 오버 헤드를 제거하기 위해 InnoDB 테이블은 모든 세컨더리 인덱스가 해당 레코드가 저장된 주소가 아닌 프라이머리 키 값을 저장하도록 구성되어 있다.
MyISAM: 인덱스를 검색하고 레코드 주소를 확인한 뒤, 레코드의 주소를 이용해 최종 레코드를 가져온다.
InnoDB: 인덱스를 검색해 레코드의 프라이머리 키 값을 확인한 뒤, 프라이머리 키 인덱스를 검색해서 최종 레코드를 가져온다.
클러스터링 인덱스
프라이머리 키 값이 비슷한 레코드 끼리 묶어서 저장하는 것을 클러스터링 인덱스라 표현한다. 프라이머리 키 값에 의해 레코드의 저장 위치가 결정된다. 프라이머리 키가 변경되면 그 레코드의 물리적인 저장 위치가 변경된다.
일반적으로 InnoDB와 같이 항상 클러스터링 인덱스로 저장되는 테이블은 프라이머리 키 기반의 검색이 매우 빠르며, 레코드의 저장이나 프라이머리 키의 변경이 상대적으로 느리다.
만약 프라이머리 키가 없는 InnoDB의 경우 어떻게 클러스터링 테이블을 구성할까? 프라이머리 키가 없는 경우 InnoDB 스토리지 엔진이 아래와 같은 우선순위로 프라이머리 키를 대체할 컬럼을 선택한다.
세컨더리 인덱스에 미치는 영향
MyISAM 테이블이나 Memory 테이블에는 프라이머리 키와 세컨더리 인덱스의 구조적 차이가 존재하지 않는다.
만약 InnoDB 테이블에서 세컨더리 인덱스가 실제 레코드가 저장된 주소를 가지고 있다면 어떻게 할까? 클러스터링 키 값이 변경될 때마다 데이터 레코드의 주소가 변경되고 그때마다 해당 테이블의 모든 인덱스에 저장된 주소값을 변경해야 한다. 이러한 오버 헤드를 제거하기 위해 InnoDB 테이블은 모든 세컨더리 인덱스가 해당 레코드가 저장된 주소가 아닌 프라이머리 키 값을 저장하도록 구성되어 있다.
예상 질문