트랜잭션 격리 수준을 변경해야하는 경우는 무엇이 있을까요?

[Sung-june27]

ex)
REPEATABLE READ → READ COMMITED
REPEATABLE READ → SERIALIZABLE

[phk1128]

REPEATABLE READ → READ COMMITTED
같은 트랜잭션에서 조회 결과가 바뀌어도 괜찮은 경우, 로그 조회, 대시보드 같은 서비스에서 주로 많이 사용합니다.

REPEATABLE READ → SERIALIZABLE
데이터 정합성을 엄격하게 지켜야하는 경우, 계좌 이체, 이벤트 선착순 기능 등에 사용합니다.

[kysub99]

정합성과 성능에 대한 요구사항이 달라지는 경우에 격리 수준을 변경해야 한다.

REPEATABLE READ -> READ COMMITTED
반복 조회의 일관성보다 동시성과 성능이 더 중요한 상황에서 불필요한 락 경합을 줄이기 위해서 사용

REPEATABLE READ -> SERIALIZABLE
Phanthom read 를 포함한 모든 동시성 이상 현상을 반드시 차단해야 하는 핵심 비즈니스 로직에서 사용

[Sung-june27]

트랜잭션 격리 수준은 데이터 정합성과 성능을 고려하여 변경합니다.

REPEATABLE READ → READ COMMITED
같은 트랜잭션 내에서 재조회 일관성이 필요하지 않고, 조회 성능과 동시성이 더 중요한 경우 REPEATABLE READ에서 READ COMMITED료 격리 수준을 낮추는 것을 고려해볼 수 있습니다.
ex) 조회 위주 API(동일 트랜잭션에서 같은 데이터를 다시 읽을 필요가 없음, 굳이 동일 조회 결과를 보장할 필요가 없음)

REPEATABLE READ → SERIALIZABLE
성능이 저하되더라도 데이터 정합성이 중요한 경우 REPEATABLE READ에서 SERIALIZABLE로 격리 수준을 변경하는 것을 고려해볼 수 있습니다.

[phk1128]