클러스터키는 PK라 할 수 있다.
예를 들어 1,2,3,5가 pk인 데이터 들이 있는데 pk가 4인 데이터를 넣을 려면 5를 뒤로 한칸 밀고 4를 지어넣어야한다. 그럼 밀어야하는 데이터가 1만, 100만이 된다면 어떨까?
클러스터 키 삽입, 갱신시에 성능 이슈 발생할 수 있다.
https://velog.io/@weseonggu/Auto-Increment-vs-UUID
PK를 지정하면 PK는 기본적으로 인덱스가 생성되고 그걸 클러스터 인덱스라 한다.
그리고 임의로 생성한 인덱스(보조인덱스)는 클러스터 인덱스를 가지고 있다.
따라서 인덱스를 생성할 때는 PK의 사이즈가 인덱스의 사이즈를 결정하게 된다.
오라클의 경우는 인덱스에 데이터의 물리적 저장 위치를 가지고 있다. 하지만 MySQL의 경우는 pk를 가지고 있고 보조인덱스를 통해서 pk를 찾고 pk를 가지고 데이터의 물리적 주소를 찾아서 데이터에 접근한다. 생각을 하면 조회시에는 오라클이 더 빠르다고 생각 할 수 있다.
mysql에서 pk가 상입이나 갱신이 될 때 마다 pk에 해당하는 데이터의 주소가 바뀌게 됩니다. 그럼 보조 인덱스에 pk가 아닌 물리적 주소를 가지게 되면 보조 인덱스도 갱신이 되어야 하기 때문에 부하가 발생합니다. 그래서 데이터의 주소는 pk만 가지고 있고 나머지 생성한 보조 인덱스는 pk를 가지고 있으므로 삽입, 갱신의 부하를 줄일 수 있습니다.
PK를 활용한 검색이 빠르고 특히 범위 검색이 빠르다.
세컨더리 인덱스들이 PK를 가지고 있어 커버링에 유리
커버링: 인덱스를 가지고 데이터를 찾아서 실제 데이터 까지 접근 할 필요가 없음