MySQL을 공부하다 보면 transaction이라는 단어를 정말 자주 만나게 됩니다. 하지만 입문 단계에서는 “여러 쿼리를 하나로 묶는 것” 정도로만 이해하고 넘어가는 경우가 많습니다. 실제로는 트랜잭션이 데이터 일관성, 잠금, 성능 문제와 깊게 연결되어 있습니다.
이 글에서는 아래 내용을 정리합니다.
- transaction이 무엇인지
- 왜 필요한지
- commit과 rollback이 어떤 의미인지
- 잠금과는 어떤 관계가 있는지
핵심은 트랜잭션은 여러 쿼리를 한 덩어리로 묶는 기능이 아니라, 데이터 상태를 일관되게 바꾸기 위한 경계라는 점입니다.
transaction이란 무엇인가
transaction은 여러 작업을 하나의 논리적 단위로 묶어 처리하는 방식입니다.
예를 들어:
- 계좌 A에서 금액 차감
- 계좌 B에 금액 증가
이 두 작업은 따로따로 성공하면 안 됩니다. 하나만 반영되면 데이터가 깨지기 때문입니다. 그래서 둘을 하나의 transaction 안에서 처리합니다.
왜 필요한가
트랜잭션이 필요한 이유는 보통 아래와 같습니다.
- 중간 상태가 외부에 보이면 안 됨
- 여러 변경이 함께 성공하거나 함께 실패해야 함
- 장애가 나도 데이터 정합성을 지켜야 함
즉, transaction은 “실패해도 괜찮게 만드는 장치”가 아니라 “실패했을 때도 일관된 상태를 지키는 장치”에 가깝습니다.
commit과 rollback은 무엇인가
commit: 지금까지의 변경을 최종 반영rollback: 지금까지의 변경을 취소
즉, transaction 안에서 쌓인 변화는 commit 전까지는 확정되지 않습니다. 문제가 생기면 rollback으로 이전 상태로 되돌릴 수 있습니다.
잠금과는 어떤 관계일까
많은 입문자가 transaction과 lock을 분리해서 생각하지만, 실제 운영에서는 둘이 자주 얽힙니다.
트랜잭션이 열려 있는 동안:
- 특정 row에 대한 잠금이 유지될 수 있고
- 다른 세션이 기다리게 될 수 있으며
- 너무 길어지면 deadlock이나 lock wait timeout으로 이어질 수 있습니다
즉, transaction은 정합성을 위한 도구이지만 동시에 잠금 범위와 시간에도 영향을 줍니다.
transaction이 길어지면 왜 위험할까
트랜잭션이 길면 잠금이 오래 유지되고, 다른 요청이 그 자원을 기다리게 됩니다.
특히 아래 같은 패턴은 조심해야 합니다.
- 트랜잭션 안에서 외부 API 호출
- 사용자 입력 대기
- 많은 row를 한 번에 갱신
이런 구조는 성능과 동시성 문제를 키우기 쉽습니다.
자주 하는 오해
1. transaction은 무조건 길수록 안전하다
오히려 너무 길면 잠금과 충돌이 커집니다.
2. transaction은 DB가 알아서 최적화해준다
DB는 경계를 지켜주지만, 트랜잭션 범위를 잘못 잡으면 성능 문제는 그대로 발생합니다.
3. 읽기 작업에는 transaction이 중요하지 않다
격리 수준과 읽기 일관성 측면에서 읽기에도 여전히 중요할 수 있습니다.
FAQ
Q. transaction은 어디까지 묶어야 하나
함께 성공하거나 함께 실패해야 하는 최소 단위로 묶는 것이 좋습니다.
Q. transaction 안에서 오래 걸리는 작업을 하면 왜 안 좋나
잠금 유지 시간이 길어지고, 동시 처리 효율이 떨어질 수 있기 때문입니다.
Q. 입문자는 무엇부터 이해하면 좋을까
commit, rollback, 잠금과의 관계를 먼저 잡는 것이 가장 좋습니다.
Read Next
- 잠금과 충돌 문제는 MySQL lock wait timeout 가이드와 MySQL deadlock 가이드로 자연스럽게 이어집니다.
- 실행 계획을 읽는 방법은 MySQL EXPLAIN 가이드에서 함께 보면 좋습니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: 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를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.