[Real MySQL 8.0] 8. 인덱스(6) 8.9~

8.9 유니크 인덱스

인덱스라기보다 제약 조건.

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

읽기, 쓰기 성능의 관점에서 

(1) 읽기

성능 차이 거의 없다. (유니크 인덱스는 1건만 읽어도 되니까.. 등등은 별 의미 없다. 인용-유니크하지 않은 세컨더리 인덱스에서 한 번 더 해야 하는 작업은 디스크 읽기가 아니라 CPU에서 컬럼값을 비교하는 작업)

(2) 쓰기

중복체크를 하지 않아도 되기 때문에 일반적인 세컨더리 인덱스의 쓰기가 더 빠르다.

MySQL에서는 유니크 인덱스의 중복 체크 과정에서 읽기 잠금, 쓰기 할 때는 쓰기 잠금을 거는데, 이 때 데드락이 빈번히 발생한다.

(도대체 유니크 인덱스 왜쓰는 건가? 개 구데기네)

 

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

요약: 정말 유일성을 보장해야 하는 경우 아니면 쓰지 말고 일반 세컨더리 인덱스 쓰자.

 

8.10 외래키

(1) 자식 테이블의 변경이 대기하는 경우

부모 레코드가 쓰기 트랜잭션T1을 시작하면, 해당 레코드에 대해 쓰기 잠금이 걸린다.

작업 중간에 자식 테이블에서 한 레코드의 pid(parent id)를 해당 레코드로 업데이트하는 트랜잭션T2이 발생했다고 하자.

그러면 T2는 T1이 쓰기 잠금을 해제할 때까지 기다려야한다.

(2) 부모 테이블의 변경 작업이 대기하는 경우

위의 경우와 반대로 T2가 T1보다 먼저 실행되면 T2가 쓰기 잠금을 획득하게 되고 T1은 T2가 끝날 때까지 기다리게 된다.