유니크란 사실 인덱스라기보다는 제약조건에 가깝다고 볼 수 있다. MySQL에서는 인덱스 없이 유니크 제약만 설정할 방법이 없다. 유니크 인덱스에서 Null도 저장될 수 있는데, Null은 특정의 값이 아니므로 2개 이상 저장될 수 있다.
유니크 인덱스와 유니크하지 않은 일반 보조 인덱스는 사실 인덱스의 구조상 아무런 차이점이 없다.
많은 사람이 유니크 인덱스가 빠르다고 생각한다. 하지만 이것은 사실이 아니다. 유니크 인덱스는 1건만 읽으면 되지만 유니크하지 않은 일반 보조 인덱스에서는 한 번더 읽어야 하므로 느리다고 이야기한다. 하지만 유니크 하지 않은 보조 인덱스에서 한 번더 해야 하는 작업은 디스크읽기가 아니라 CPU에서 컬럼값을 비교하는 작업이기 떄문에 이는 성능상의 영향이 거의 없다고 볼 수 있다. 유니크 하지 않은 보조 인덱스는 중복된 값이 허용되므로 읽어야할 레코드가 많아서 느린것잇지, 인덱스 자체의 특성 때문에 느린 것이 아니라는 것이다.
새로운 레코드가 INSERT 될거나 인덱스 컬럼의 값이 변경되는 경우에는 인덱스 쓰기 작업이 필요하다. 그런데 유니크 인덱스의 키값을 쓸 때는 중복된 값이 있는지 없는지 체크하는 과정이 한 단계 더 필요하다. 그래서 일반 보조 인덱스의 쓰기보다 느리다. 그런데 MySQL에서는 유니크 인덱스에서 중복된 값을 체크할 때는 읽기 잠금을 사용하고, 쓰기를 할 떄는 쓰기 잠금을 사용하는데 이 과정에서 데드락이 아주 빈번히 발생한다.
InnoDB 스토리지 엔진에는 인덱스 키의 저장을 버퍼링하기 위해 인서트 버퍼가 사용된다. 그래서 인덱스의 저장이나 변경 작업이 상당히 빨리 처리되지만 안타깝게도 유니크 인덱스는 반드시 중복 체크를 해야 하므로 작업 자체를 버퍼링 하지 못한다. 이 때문에 유니크 인덱스는 일반 보조 인덱스 보다 느리다.
꼭 필요한 경우하면 유니크 인덱스를 생성하는 것은 당연하다. 하지만 더 성능이 좋아질 것으로 생각하고 불필요하게 유니크 인덱스를 생성하지 않는 편이 좋다. 그리고 하나의 테이블에서 같은 컬럼에 유니크 인덱스와 일반 인덱스를 각각 중복해서 생성해 둔 경우가 가끔 있는데, MySQL의 유니크 인덱스는 일반 다른 인덱스와 같은 역할을 하므로 중복해서 인덱스를 생성할 필요는 없다.