8.9 유니크 인덱스

8.9 유니크 인덱스

8.9.1 유니크 인덱스와 인반 세컨더리 인덱스의 비교

인덱스의 구조상 아무런 차이점이 없다.

읽기와 쓰기 성능 관점에서 살펴보자.

8.9.1.1 인덱스 읽기

유니크 인덱스가 세컨더리 인덱스보다 더 빠른가?

nope. 유니크 하지 않은 세컨더리 인덱스는 중복된 값이 허용되므로

읽어야할 레코드가 많아서 느린 것이지 인덱스 자체의 특성때문에 느린것이 아님.

하나의 값을 검색할 경우, 실행계획이 다르긴 하지만 인덱스의 성격이 유니크한지 아닌지의 차이일 뿐 큰 차이는 없다

읽어야할 레크드 수가 같다면 성능 차이는 미미하다.

8.9.1.2 인덱스 쓰기

유니크 인덱스의 키 값을 쓸 때는 중복된 값이 있는지 체크하는 과정이 더 필요함.

=> 세컨더리 인덱스 쓰기 보다 느림

유니크 인덱스 중복값 체크 시 읽기 잠금 발생

쓰기 할 때는 쓰기 잠금 발생

=> 데드락이 빈번히 발생.

InnoDB는 인덱스 키의 저장을 버퍼링 하기 위해 체인지 버퍼를 사용함.

인덱스 쓰기 작업이 빨리 처리되지만 유니크 인덱스는 반드시 중복 체크를 해야 하므로

작업 자체를 버퍼링 하지 못함.

=> 유니크 인덱스가 세컨더리 인덱스보다 변경 작업이 느림

8.9.2 유니크 인덱스 사용 시 주의 사항

꼭 필요하다면 당연히 추가하지만 성능을 기대하며 생성하는 것 X

유니크 인덱스는 일반 인덱스와 같은 열할을 하므로 중복해서 한 컬럼에 생성할 필요 X

유니크 인덱스는 쿼리 실행계획과 테이블 파티션에 영향을 미침(10장 '실행계획', 13장 '파티션' 에서..)

=> 유일성을 보장할 필요 없으면 세컨더리 인덱스를 고려해보자.