오늘 MySQL 기본 격리 레벨이 뭔지 의논할 일이 있었다.
READ COMMITTED 이냐 REPEATABLE READ 이냐 였다.
결론부터 말하자면 MySQL 은 REPEATABLE READ 이다.
출처 : https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html
(오라클 등 많은곳에서 READ COMMITTED 가 기본이긴 하다)
관련해서 Real MySQL 책을 찾아 보다가, 내용이 새록새록 다시금 떠올라 정리해 본다.
MySQL 의 기본 격리 레벨은 REPEATABLE READ 이다.
책에서 다음과 같이 소개한다.
(1)
REPEATABLE READ는 MySQL 의 InnoDB 스토리지 엔진에서 기본적으로 사용되는 격리 수준이다.
(2) 바이너리 로그를 가진 MySQL의 장비에서는REPEATABLE READ격리 수준 이상을 사용해야 한다.
MySQL 을 쓰다보면 대부분 InnoDB 를 사용하기 때문에 REPEATABLE READ 가 채택되고 있다고 보면 될 것이다.
근데 재미있는 점은 (2) 의 내용인데, REPEATABLE READ 가 강제된다는 것이다.
Aurora MySQL 의 읽기 인스턴스도 REPEATABLE READ 가 강제된다.
오로라 레플리케이션이 바이너리로그 기반으로 동작하는 것인데, 같은 맥락에서 강제되는게 아닐가 생각된다.
Aurroa MySQL 공식문서 에서는 다음과 같이 소개하고 있다.
기본적으로 읽기 전용 Aurora 복제본으로 구성된 Aurora MySQL DB 인스턴스에서는 항상 REPEATABLE READ 격리 수준을 사용합니다.
이 DB 인스턴스에서는 SET TRANSACTION ISOLATION LEVEL 문은 모두 무시하고 계속해서 REPEATABLE READ 격리 수준을 사용합니다.
[중요 내용 추가!]
아래에 따르면 2020년 1월에 읽기 인스턴스도 5.7 이상이면 READ COMMITTED 를 지원 한다고 한다.
https://aws.amazon.com/ko/about-aws/whats-new/2020/01/amazon-aurora-supports-the-read-committed-isolation-level-on-read-replicas/
REPEATABLE READ 와 READ COMMITTED 격리 수준의 성능 차이는 미비하다.
책에서는 100G 테이블 기준으로 7%의 미비한 성능하락이 있다고 말하고 있다.
30G 테이블 기준으로는 오히려 REPEATABLE READ 가 2% 더 빠르다.
더 높은 격리수준을 가지면서 이정도는 괜찮은 트레이드오프라고 생각하는것 같다. (아니 오히려 빠른건가?)
즉 대규모 배치가 아니고서야 READ COMMITTED 를 굳이 쓸 필요는 없다.
(대규모 배치여도 트랜잭션을 건별로 처리하면 된다.)
내생각
사실 격리수준이 높은건, 하이버네이트를 쓴다면 그다지 장점이 되지 않는다.
트랜잭션 내에서 하나의 엔티티를 두번 가져오더라도 1차 캐시에 의해 sql 이 2번 날아가지 않기 때문이다.
1차캐시는 차치 하고서라도, 한 트랜잭션에서 같은쿼리를 2번 날릴 일이 뭐가 있겠으며 꼭 보장되어야 하는 경우가 있긴 한가 싶다.
결론
- 기본값은
REPEATABLE READ가 맞다. - 바이너리로그를 활성화 하면
REPEATABLE READ이상으로 강제 된다. REPEATABLE READ는 계륵같은 존재 이지만, 어짜피 변경도 불가능한데다 OLTP 에서 딱히 성능 하락이 많지 않으니 그냥 쓰고 있다- Aurora MySQL 도 읽기 인스턴스에 대해서는
REPEATABLE READ가 강제됐었다. - 다만 2020/01 에
READ COMMITTED도 지원 하도록 변경되었다. (혹시 2번 제약도 풀렸을수도..)
REPEATABLE READ 는 신경 써야 할게 좀 많은것 같다.
MVCC와 undo영역도 알아야하고, Gap Lock 에 대해서도 알아야 한다.
따로 다뤄보도록 하자.
