[Real MySQL] 4-2. 아키텍쳐: InnoDB 스토리지 엔진 아키텍쳐 (3)

7. 클러스터링

 

클러스터형 인덱스

• 테이블 자체가 프라이머리 키 인덱스와 결합되어 저장되는 구조
• InnoDB에서는 프라이머리 키가 클러스터형 인덱스 역할을 하며, 해당 인덱스 안에 테이블의 모든 컬럼 데이터가 함께 저장됨.

항목	자세한 설명
테이블 = 인덱스	별도의 테이블 파일에 데이터를 따로 저장하지 않음 프라이머리 키 인덱스의 B+ Tree 구조의 리프(Leaf) 노드에 모든 데이터가 포함됨.
정렬 저장	이 구조 때문에 데이터가 프라이머리 키 순서대로 물리적으로 정렬되어 저장됨  → 범위 조회에 특히 효율적.

 

보조 인덱스

• 프라이머리 키가 아닌 다른 컬럼에 대해 생성한 인덱스 (예: email, username 등).

항목	자세한 설명
구조적 특징	인덱스 컬럼 값 + 해당 레코드의 프라이머리 키 값만을 저장함
데이터 접근 방식	1. 보조 인덱스를 통해 일치하는 프라이머리 키를 찾음 2. 해당 PK로 다시 클러스터형 인덱스(B+ Tree)를 탐색 → 실제 레코드를 조회함.
⚠️ 주의점	이중 접근이 필요하므로, 보조 인덱스를 통한 조회는 PK 조회보다 느릴 수 있음. (특히 선택도가 낮은 경우 더더욱)

 

프라이머리 키의 가중치

항목	자세한 설명
우선적 인덱스 설정	InnoDB는 프라이머리 키가 클러스터형 인덱스이기 때문에, 데이터 저장 구조의 핵심이 됨. 따라서 시스템 차원에서도 가장 우선적으로 고려되는 인덱스임.
인덱스 설계 영향	프라이머리 키는 모든 보조 인덱스에도 자동으로 포함되므로, 너무 길거나 자주 변경되는 컬럼은 PK로 부적절함.
효율성 측면	프라이머리 키가 짧고 고유하며 자주 정렬, 범위 검색에 쓰인다면 성능상 매우 효율적임.
✅ 설계 팁	프라이머리 키는 가급적 단순하고 불변이며 정수 기반(auto_increment 등)으로 설계하는 것이 좋음.