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