Primary key (Clustering Index)
- InnoDB 테이블은 기본적으로 모두 Primary key에 의해서 클러스터링되어 있음
- Primary key가 정의되지 않은 테이블은 아래 순서대로 내부 PK를 선정함
- Unique index로 정의된 컬럼이 있으면 그 중에서 하나를 내부적인 PK로 선정하여, 이 컬럼값으로 Clustering 구축
- Unique index가 없으면, 내부적으로 6바이트 숫자값을 이용한 PK를 생성해서 Clustering 구축
(내부적인 6바이트 숫자값은 사용자가 사용할 수 없음 - 숨겨진 컬럼정도로 해석) - Primary key 값에 의해서 레코드의 물리적 위치가 결정되며, Primary key값 밑에 모든 레코드 데이터가 저장됨
- 대량의 INSERT가 실행되는 경우, PK에 의해서 정렬되지 않은 경우에는 상당히 느려질 수 있음
- - INSERT를 위해서는 해당 데이터 페이지와 인덱스 페이지를 먼저 읽어야 함
- 매 INSERT 문장마다, 필요한 인덱스 페이지나 데이터 페이지가 각각 다르다면 매번 해당 페이지를 읽어야 함
- 이 경우, 페이지의 분할 및 프레그멘테이션을 유발하며, Page의 공간을 효율적으로 사용하지 못하게 될 수도 있음 - PK에 대한 범위 검색은 빠름 (PK에 의해서 Clustering되어 있으므로)
- PK를 변경하는 작업은 테이블 전체의 재구성이 필요하므로 느림
Secondary Index
- Primary key가 아닌 모든 인덱스는 레코드의 주소가 아닌 Primary key 값을 가짐
- PK가 아닌 인덱스로 검색 시, 실제 레코드를 찾기 위해서는 2번의 검색이 필요함
- 레코드의 위치가 변경되어도 나머지 모든 인덱스의 내용을 변경할 필요 없음(해당 레코드의 주소값을 가지지 않으므로)
- PK의 값이 긴 경우에는, 전체 인덱스의 사이즈가 매우 커질 수 있음 - InnoDB 테이블의 인덱스는 트랜잭션 정보를 추가적으로 가지고 있음
- Covering index용 쿼리에서 레코드의 Visibility를 판단하기 위함 - Unique 가 아닌 보조 인덱스는 Insert Buffer를 통해서 즉시 Index page에 추가되지 않음
- 실시간으로 인덱스의 변경을 적용하지 않아도 되기 때문에 인덱스 변경이 빠름
- 시스템이 한가해지면, Insert buffer merge Thread가 병합 작업 수행
댓글 없음:
댓글 쓰기