MySQL 트랜잭션을 공부하다 보면 isolation level이라는 개념을 만나게 됩니다. 처음에는 조금 추상적으로 느껴지지만, 실제로는 “한 트랜잭션이 다른 트랜잭션의 변경을 어떤 시점에 볼 수 있는가”를 정하는 매우 중요한 기준입니다.
이 글에서는 아래 내용을 정리합니다.
- isolation level이 무엇인지
- 왜 중요한지
read committed,repeatable read를 어떻게 이해하면 좋은지- 잠금과는 어떤 관계가 있는지
핵심은 격리 수준은 단순한 이론이 아니라, 읽기 일관성과 동시성 사이의 균형을 정하는 선택지라는 점입니다.
isolation level이란 무엇인가
isolation level은 동시에 실행되는 트랜잭션들이 서로의 변경을 얼마나 보게 할지를 정하는 규칙입니다.
즉:
- 다른 트랜잭션의 아직 확정되지 않은 변경을 볼 수 있는가
- 같은 쿼리를 다시 했을 때 같은 결과를 보장하는가
- 중간에 새 row가 보일 수 있는가
같은 문제와 연결됩니다.
왜 중요한가
격리 수준은 데이터 정합성뿐 아니라 성능과 동시성에도 영향을 줍니다.
- 더 강한 일관성
- 더 많은 제약과 잠금 가능성
반대로:
- 더 높은 동시성
- 더 많은 읽기 변화 가능성
처럼 균형이 바뀔 수 있습니다.
자주 보는 수준들
입문 단계에서는 아래 두 수준부터 이해하면 좋습니다.
1. Read Committed
커밋된 데이터만 읽을 수 있게 하는 수준입니다.
즉, 다른 트랜잭션이 아직 commit하지 않은 변경은 보이지 않습니다. 하지만 같은 트랜잭션 안에서도 다시 읽을 때 값이 달라질 수 있습니다.
2. Repeatable Read
같은 트랜잭션 안에서 같은 row를 다시 읽으면 일관된 값을 보게 하려는 수준입니다.
MySQL에서는 기본적으로 많이 쓰이는 수준이고, 읽기 일관성 측면에서 중요한 기준이 됩니다.
왜 lock과 연결될까
격리 수준이 달라지면 읽기와 쓰기의 상호작용 방식도 달라질 수 있습니다. 어떤 수준에서는 더 엄격한 일관성을 위해 충돌 가능성이 커질 수 있고, 어떤 수준에서는 더 많은 변화가 읽기 결과에 반영될 수 있습니다.
즉, isolation level은 단순히 읽기 정책이 아니라 잠금과 충돌 패턴에도 영향을 주는 설정입니다.
입문자가 어떻게 이해하면 좋을까
너무 이론으로만 보기보다 아래 질문으로 이해하면 좋습니다.
- 같은 트랜잭션 안에서 다시 읽었을 때 결과가 달라질 수 있는가
- 다른 트랜잭션의 변경이 언제 보이는가
- 일관성과 동시성 중 어디에 더 무게를 두는가
이 관점으로 보면 격리 수준이 훨씬 덜 추상적으로 느껴집니다.
자주 하는 오해
1. 격리 수준은 높을수록 무조건 좋다
일관성은 좋아질 수 있지만, 동시성과 성능 비용도 커질 수 있습니다.
2. 격리 수준은 DB 설정이라 앱과 상관없다
실제로는 읽기 패턴, 트랜잭션 길이, 충돌 문제와 모두 연결됩니다.
3. repeatable read면 모든 문제가 사라진다
격리 수준은 중요한 도구지만, 긴 트랜잭션이나 잘못된 접근 패턴까지 자동으로 해결해주지는 않습니다.
FAQ
Q. 입문자는 무엇부터 구분하면 좋을까
read committed와 repeatable read 차이부터 잡는 것이 가장 좋습니다.
Q. 격리 수준이 deadlock에도 영향을 주나
직접적인 원인은 접근 순서와 잠금 패턴이지만, 격리 수준은 그 상호작용 방식에 영향을 줄 수 있습니다.
Q. 기본값을 그냥 써도 되나
많은 경우 가능하지만, 서비스의 일관성 요구와 충돌 패턴을 이해한 뒤 선택하는 것이 더 좋습니다.
Read Next
- 트랜잭션 기본 개념은 MySQL transaction 가이드와 가장 잘 이어집니다.
- 잠금 충돌 문제는 MySQL lock wait timeout 가이드와 MySQL deadlock 가이드를 같이 보면 좋습니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.