•
인덱스라기보단 제약조건에 가깝다.
•
말 그대로 테이블이나 인덱스에 같은 값이 2개 이상 저장될 수 없음을 의미하며 MySQL에선 유니크 인덱스 없이 이런 제약조건을 사용할 방법이 없다.
•
NULL도 저장될 수 있으며 NULL은 특정값이 아니므로 2개 이상 저장이 가능, 프라이머리 키는 자동으로 NULL을 허용하지 않는 유니크 속성이 부여된다.
1. 유니크 인덱스와 일반 세컨더리 인덱스의 비교
•
유니크 인덱스와 유니크하지 않은 일반 세컨더리 인덱스는 사실 인덱스의 구조상 아무런 차이점이 없다.
1.
인덱스 읽기
•
많은 사람들이 유니크 인덱스가 빠르다고 생각하지만 이는 사실이 아니다.
◦
유니크 인덱스는 1건만 읽지만 세컨더리 인덱스는 여러 건을 읽기 때문에 더 느리다는 이야기 때문이다.
•
유니크하지 않은 세컨더리 인덱스에서 한 번 더 해야 하는 작업은 디스크 읽기가 아닌 CPU에서 칼럼값을 비교하는 작업이기 때문에 이는 성능성 영향이 매우 적다고 볼 수 있다.
•
유니크하지 않은 세컨더리 인덱스는 중복된 값이 허용되므로 읽어야할 레코드가 많아 느린 것이지, 인덱스 자체의 특성때문은 아니다.
2.
인덱스 쓰기
•
새로운 레코드가 INSERT되거나 인덱스 칼럼의 값이 변경되는 경우에는 인덱스 쓰기 작업이 필요하다.
•
유니크 인덱스의 키 값을 쓸때는 중복된 값이 있는지 없는지 체크하는 과정이 한 단계 더 추가된다.
•
이때문에 유니크하지 않은 세컨더리 인덱스의 쓰기보다 느리다.
◦
이를 체크하기 위해 유니크 인덱스의 중복값을 확인할 때, 읽기 잠금을 사용하고 쓰기 시에는 쓰기 잠금을 사용하므로 데드락이 아주 빈번히 발생한다.
◦
외에도 InnoDB 스토리지 엔진은 인덱스 키의 저장을 버퍼링하기 위해 체인지 버퍼가 사용된다.
◦
그래서 인덱스의저장이나 변경 작업이 상당히 빨리 처리되지만 유니크 인덱스는 중복 체크를 해야하므로 작업 자체를 버퍼링할 수 없으며 이때문에 더 느리게 실행됟나.
2. 유니크 인덱스 사용 시 주의사항
•
꼭 필요한 경우라면 유니크 인덱스를 생성하는 것이 당연, 하지만 더 성능이 좋아질 것이라고 생각하고 불필요하게 생성하지 않는 것이 좋다.
•
같은 컬럼에 유니크 인덱스와 일반 세컨더리 인덱스를 거는 경우 불필요하므로 하나만 생성하는 것이 좋다. 이는 당연하게도 프라이머리 키와 유니크 인덱스 간의 관계도 동일하다.
