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