Unique index

유니크는 인덱스라기보다는 제약 조건에 가깝다고 볼 수 있다.

유니크는 테이블이나 인덱스에 같은 값이 2개 이상 저장될 수 없음을 의미하는데, MySQL에서는 인덱스 없이 유니크 제약만 설정할 방법이 없다. 유니크 인덱스에서도 2개 이상의 NULL이 지정될 수 있다.

• MySQL은 유니크 제약 조건을 설정하면 해당 컬럼에 대해 자동으로 유니크 인덱스를 생성한다.

InnoDB 테이블의 PK는 클러스터링 키의 역할도 하므로 유니크 인덱스와는 근본적으로 다르다.

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

유니크 인덱스와 유니크하지 않은 세컨더리 인덱스는 구조상 아무런 차이점이 없다. 그럼 어떤 차이가 있는가?

인덱스 읽기

유니크 인덱스가 빠르다고 생각하지만 사실이 아니다. 유니크 인덱스는 1건만 읽으면 되지만 유니크하지 않은 세컨더리 인덱스에서는 레코드를 한 번 더 읽어야 해서 느리다고 얘기한다.

하지만 일반 세컨더리 인덱스에서 한 번 더 하는 작업은 disk I/O가 아니라 CPU에서 컬럼값을 비교하는 작업이기 때문에 성능상 영향이 거의 없다.

유니크하지 않은 세컨더리 인덱스는 중복을 허용하기 때문에 읽어야 할 레코드가 많아서 느린 것이지, 인덱스 자체의 특성 때문에 느린 것이 아니다. 읽어야 할 레코드가 1개냐 2개 이상이냐의 차이만 있을 뿐, 건수가 같다면 성능은 똑같다.

인덱스 쓰기

INSERT 혹은 컬럼값이 변경되는 과정에서 인덱스 쓰기 작업이 필요하다.

그런데 유니크 인덱스의 키값을 쓸 때는 중복된 값이 있는지 없는지 체크하는 과정이 한 번 더 필요하다. 그래서 유니크하지 않은 세컨더리 인덱스의 쓰기보다 느리다.

MySQL에서는 유니크 인덱스에서 중복 값을 체크할 때 읽기 잠금을 사용하고, 쓰기를 할 때는 쓰기 잠금을 사용하는데 이 과정에서 데드락이 아주 빈번하게 발생한다.

또한 InnoDB 스토리지 엔진에는 인덱스 키의 저장을 버퍼링 하기 위해 체인지 버퍼가 사용되어 인덱스의 저장이나 변경 작업이 상당히 빨리 처리되지만, 유니크 인덱스는 반드시 중복 체크를 하기 때문에 작업을 버퍼링하지 못한다. 이 때문에 유니크 인덱스는 일반 세컨더리 인덱스보다 변경 작업이 더 느리다.

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

성능이 더 좋아질 것이라고 불필요한 유니크 인덱스 생성을 자제해야 한다. 그리고 하나의 테이블에서 같은 컬럼에 유니크 인덱스와 일반 인덱스를 중복해서 생성해 둔 경우가 있는데, MySQL의 유니크 인덱스는 일반 다른 인덱스와 같은 역할을 하므로 중복해서 생성할 필요는 없다.

create table tb_unique(
	id INTEGER NOT NULL,
	nick_name VARCHAR(100),
	PRIMARY KEY (id),
	UNIQUE INDEX ux_nickname (nick_name),
	INDEX ix_nickname (nick_name)
);

위 테이블에서 이미 nick_name이라는 컬럼에 유니크 인덱스인 ux_nickname이 있기 때문에 ix_nickname 인덱스를 생성하지 않아도 된다는 것이다. 이미 유니크 인덱스도 일반 세컨더리 인덱스와 같은 역할을 동일하게 수행할 수 있다.

가끔 같은 컬럼에 대해 PK와 유니크 인덱스를 동일하게 생성한 경우도 있는데 이 또한 중복이다.

유니크 인덱스는 쿼리 실행 계획이나 테이블 파티션에 미치는 영향이 존재한다.

결론적으로 유일성이 반드시 보장돼야 하는 컬럼에는 유니크 인덱스를 생성하되, 불필요하다면 일반 세컨더리 인덱스를 생성하는 방법을 고려해야 한다.