728x90
트랜잭션이란?
트랜잭션은 데이터베이스에서 하나의 작업 단위를 의미
일련의 SQL 문장이 모두 성공해야만 반영되고, 중간에 하나라도 실패하면 전체가 취소(rollback) 되는 구조
📌 은행 계좌 이체 예시
1. A → B 계좌로 돈 이체
2. A 계좌에서 출금, B 계좌에 입금
👉중간에 B 계좌 입금 실패 시 → A 계좌 출금도 되돌려야 함
트랜잭션의 특징 (ACID)
- 원자성(Atomicity)
- 트랜잭션은 전체가 수행되거나, 전혀 수행되지 않거나
- 중간 실패 시 rollback 가능
- 일관성(Consistency)
- 트랜잭션이 완료되면 DB는 항상 일관된 상태로 유지
- 예: 잔액 총합은 항상 동일
- 격리성(Isolation)
- 여러 트랜잭션이 동시에 실행되더라도 서로 간섭하지 않음
- 지속성(Durability)
- 트랜잭션이 성공적으로 끝나면 그 결과는 영구 반영됨
- 시스템 장애가 나도 데이터는 복구 가능
트랜잭션의 격리 수준
트랜잭션끼리 서로 간섭하지 않도록 하기 위한 동시성 제어 방식
격리 수준이 낮을 수록 성능은 좋진만 오류 가능성이 높고, 높을 수록 정합성은 높지만 성능은 떨어질 수 있음
📌 정합성: 데이터가 서로 모순 없이 일관되게 일치되는 상태
트랜잭션의 충돌로 생기는 문제점
| 문제 | 설명 |
| Dirty Read | 커밋되지 않은 데이터를 다른 트랜잭션이 읽음 |
| Non-Repeatable Read | 같은 쿼리를 두 번 실행했는데 결과가 다름 |
| Phantom Read | 범위 조회 시 처음에 없던 데이터가 두 번째 조회에 나타남 |
| Lost Update | 두 트랜잭션이 같은 데이터를 덮어씌움 |
트랜잭션 격리 수준 4단계 (낮음 → 높음)
1. Read Uncommitted (읽기 미확정)
- Dirty Read 발생 가능
- 성능은 빠르지만, 정합성은 최악
- 커밋 안 된 데이터를 읽을 수 있음
- 실무에서는 거의 사용 ❌
📌 예시
A 트랜잭션이 잔고를 100 → 200으로 바꾸고 아직 커밋 안 했는데,
B 트랜잭션이 200을 읽어버림 → 이후 A가 롤백하면 B는 잘못된 값 봄
2. Read Committed (읽기 확정)
- Dirty Read는 방지
- Non-Repeatable Read 가능
- Oracle, SQL Server의 기본 설정
- SELECT 할 때마다 최신 커밋된 값 읽음
📌 예시
B 트랜잭션이 두 번 SELECT 하는 사이 A 트랜잭션이 값 수정 후 커밋
→ B는 같은 쿼리를 두 번 했지만 다른 값을 보게 됨
3. Repeatable Read (반복 가능 읽기)
- Dirty Read, Non-Repeatable Read 방지
- Phantom Read는 가능
- 트랜잭션 시작 시점의 스냅샷 버전을 유지
- SELECT 여러 번 해도 같은 결과
📌 예시
A가 값을 수정하고 커밋해도, B는 자기 트랜잭션 시작 당시 버전만 읽음
→ 같은 데이터를 계속 SELECT 하면 결과는 고정됨
4. Serializable (직렬화 가능)
- 모든 트랜잭션이 순차적으로 실행된 것처럼 처리
- Dirty/Non-Repeatable/Phantom Read 모두 방지
- 성능 최악, 락 많이 사용
- 완벽한 정합성이 필요한 경우에만 사용
SELECT 시점에 해당 조건의 행이 없으면 다른 트랜잭션이 INSERT도 못함
정리
| 격리수준 | Dirty Read | Non- Repeatable Read | Phantom Read | 사용 예시 |
| READ UNCOMMITTED | O | O | O | 거의 사용x |
| READ COMMITTED | X | O | O | 실시간 대시보드, 일반 웹 앱 |
| REPEATABLE READ | X | X | O | MySQL 기본값, 금융 거래 |
| SERIALIZABLE | X | X | X | 항공기 예약, 전자 투표 |
실무 사용 예시
- 조회가 많은 시스템 (검색 등) : Read Committed, Repeatable Read
- 정합성이 중요한 금융/회계: Repeatable Read, Serializable
- 속도 우선, 데이터 정합성 중요치 않음 : Read Committed
- 단순 조회 (게시글 보기 등) : Read Committed
- 통계 계산, 리포트 생성: Repeatable Read (안정된 값 필요)
InnoDB의 Undo, Redo
InnoDB는 MySQL의 대표적인 스토리지 엔진, 스토리지 엔진이란 MySQL에서 데이터를 실제로 저장, 관리, 검색하는 역할을 담당하는 모듈로 테이블마다 어떤 엔진을 쓸지 선택할 수 있음
👉 InnoDB는 ACID 보장을 위해 아래 두 가지 로그를 사용
1. Undo Log
- 트랜잭션이 변경한 내용을 되돌릴 수 있도록 기록
- 트랜잭션이 롤백될 경우, 이 로그를 사용해서 변경 전 상태로 복원
- MVCC 구현 시에도 사용 = 트랜잭션 격리에 기여
2. Redo Log
- 디스크에 기록하기 전, 변경된 데이터를 영구적으로 기록
- 시스템 장애 시 Redo Log를 이용해 데이터 복구 가능
- ACID의 `지속성` 보장
❓ MVCC (Multi-Version Concurrency Control, 다중 버전 동시성 제어)
DB에서 여러 사용자가 동시에 데이터를 읽고 쓸 때, 락 없이도 일관된 읽기를 제공하는 동시성 제어 기법
읽기에도 트랜잭션이 필요한 경우
단순 SELECT도 트랜잭션 안에서 수행해야 하는 경우 가있음.
- 일관된 데이터를 읽기 위해 (MVCC 사용)
- `Repeatable Read 수준`에서, 트랜잭션 시작 시점의 데이터를 스냅샷으로 고정해서 읽음
- 다른 트랜잭션의 변경이 보이지 않음
- 다중 SELECT 간 정합성을 유지할 때
- 예: 페이지네이션 → 1페이지와 2페이지 SELECT 결과가 다르면 이상함
- 트랜잭션으로 묶으면 같은 스냅샷에서 읽게 됨
- 읽기 중에도 Lock을 걸어야 하는 경우 (SELECT FOR UPDATE)
- 해당 행을 다른 트랜잭션이 수정 못하게 잠금
- 주로 재고 수량 감소, 좌석 예매 등에서 사용
728x90