장바구니 미션을 하다가 아래와 같은 리뷰를 받았다.
유니크 인덱스를 설정하면 조회시 성능상에 이점이 있다는 것을 처음 알게 되었는데 요리조리 검색해봐도 잘 나오지 않았다.
RealMySQL이라는 책을 읽으면서 왜 그런지 알게 되었고 포스팅을 하게 되었다.
MySQL에서의 Unique Index
MySQL에서는 컬럼에 유니크 제약을 걸면 해당 컬럼에 인덱스가 수반된다.
알아본 결과, 유니크라서 더 조회가 빠르다기보단 인덱스가 수반되어서 더 빠른 것이였다! 👍
인덱스
- 컬럼의 값과 해당 레코드가 저장된 주소를 key와 value쌍으로 저장한다.
- 매번 정렬하여 저장한다.
인덱스가 필요한 이유
- READ가 빠르기 때문에
- READ가 빨라야 하는 이유 : 전자식 장치인 CPU쪽은 발달이 많이 됐지만 기계식 장치인 디스크 드라이브는 그만큼 발달되지 않아서 CRUD를 하기위해 드는 시간이 길다.
CRUD중 특히 많이 하는 것이 R이므로 R을 최적화할 수 있어야 하는데 그러기 위해 필요한 것이 인덱스이다.
- 대신 CREATE, UPDATE, DELETE가 느림
따라서 테이블의 인덱스를 하나 더 추가할지 말지는 데이터의 저장 속도를 어디까지 희생할 수 있는지, 읽기 속도를 얼마나 더 빠르게 만들어야 하는지에 따라 결정된다.
유니크 인덱스와 세컨더리 인덱스
프라임 키가 아닌데, 인덱싱을 한 것을 세컨더리 인덱스라고 한다.
프라임 키는 클러스터링이라던가 다른 추가되는 기능들이 많으므로, 이를 제외하고 세컨더리 인덱스와 유니크 인덱스를 비교해보자.
유니크 인덱스와 세컨더리 인덱스는 인덱스 구조상으로 아무런 차이점이 없다.
하지만 조회와 쓰기시엔 성능상의 차이가 있다.
인덱스 조회
유니크 인덱스는 세컨더리 인덱스보다 조회시 더 빠르다고 생각하지만 이는 정확히 말하면 틀리다.
인덱스를 읽는 것 자체는 시간이 같으나, 이는 유니크 인덱스는 따로 특별한 과정이 있는게 아니라 읽을 레코드 수가 적기 때문이다.
세컨더리 인덱스는 유니크 인덱스와 동일하게 디스크 읽기를 통해 데이터를 가져온 뒤, CPU에서 컬럼값을 비교하는 과정에서 좀 더 진행하나 해당 과정은 성능상에 영향이 거의 없다.
인덱스 쓰기
새로운 레코드가 추가되거나 인덱스 컬럼의 값이 변경될 때, 인덱스 쓰기 작업이 필요하다.
이 때, 유니크 인덱스의 경우 키 값을 쓸 때 중복된 값이 있는지 확인하는 과정이 추가로 필요하다.
MySQL에서는 유니크 인덱스에서 중복된 값을 체크할 때 읽기 잠금을 사용하고, 쓰기를 할 때는 쓰기 잠금을 사용한다.
👍