격리 수준

T1                              T2
───                             ───
UPDATE 잔고 = 50만원 (100→50)
                                READ 잔고 → 50만원 (Dirty Read!)
ROLLBACK (잔고 = 100만원으로 복원)
                                50만원 기반으로 비즈니스 로직 수행
                                → 잘못된 데이터 기반의 결과!

T1                              T2
───                             ───
READ 잔고 → 100만원
                                UPDATE 잔고 = 50만원
                                COMMIT
READ 잔고 → 50만원              
  ↑ 같은 트랜잭션 내에서 값이 변했다!

T1                              T2
───                             ───
SELECT COUNT(*) FROM 주문 
  WHERE 날짜 = '2024-01-01'
  → 5건
                                INSERT INTO 주문 (날짜 = '2024-01-01')
                                COMMIT
SELECT COUNT(*) FROM 주문
  WHERE 날짜 = '2024-01-01'
  → 6건 ← 팬텀 행 출현!

동시성 높음 ◀──────────────────────────────────▶ 안전성 높음
성능 좋음                                         성능 낮음

READ         READ          REPEATABLE       SERIALIZABLE
UNCOMMITTED  COMMITTED     READ

T1                              T2
───                             ───
BEGIN
UPDATE 상품 SET 가격 = 0 
  WHERE id = 1;
  (원래 가격: 10000)
                                BEGIN
                                SET ISOLATION LEVEL READ UNCOMMITTED
                                SELECT 가격 FROM 상품 WHERE id = 1
                                → 0 ← 커밋 안 된 값을 읽음!
                                -- 이 값을 기반으로 주문 생성
                                INSERT INTO 주문 (상품id, 가격) VALUES (1, 0)
                                COMMIT
ROLLBACK
  (가격: 10000으로 복원)
                                -- 주문은 가격 0으로 남아있음 → 데이터 불일치!

T1 (READ COMMITTED)             T2
───                             ───
BEGIN
                                BEGIN
                                UPDATE 직원 SET 급여 = 400
                                  WHERE id = 1  (원래: 300)
SELECT 급여 FROM 직원 
  WHERE id = 1
  → 300 (T2 미커밋이므로 커밋된 값을 읽음)
                                COMMIT
SELECT 급여 FROM 직원
  WHERE id = 1
  → 400 (T2 커밋 완료, 새 값 읽음)
  ↑ Non-Repeatable Read 발생!
COMMIT

쿼리 시작 SCN = 1000

데이터 블록 SCN = 1005 (최근 변경됨)
  → SCN 1005 > 1000이므로 이 블록은 변경됨을 인식
  → Undo Segment를 사용하여 SCN 1000 시점의 값을 복원
  → CR(Consistent Read) 블록 생성 후 반환

결과: 쿼리 시작 시점의 일관된 데이터를 반환

T1 (REPEATABLE READ)            T2
───────────────────            ─────────────
BEGIN (스냅샷 생성 시점!)
SELECT 잔고 FROM 계좌 
  WHERE id = 1
  → 100만원
                                BEGIN
                                UPDATE 계좌 SET 잔고 = 50만원
                                  WHERE id = 1
                                COMMIT
SELECT 잔고 FROM 계좌
  WHERE id = 1
  → 100만원 ← 스냅샷 읽기! 변경 무시!
COMMIT
(트랜잭션 종료 후에야 50만원으로 보임)

1. Consistent Read (SELECT)
   → MVCC 스냅샷을 사용하므로 팬텀 행이 보이지 않음
   → 트랜잭션 시작 시점 이후의 INSERT는 스냅샷에 없음

2. Locking Read (SELECT ... FOR UPDATE / FOR SHARE)
   → Gap Lock + Next-Key Lock을 사용하여 범위 잠금
   → 다른 트랜잭션의 INSERT를 물리적으로 차단

Gap Lock 예시:
  SELECT * FROM 주문 WHERE 금액 BETWEEN 100 AND 200 FOR UPDATE;
  → (100, 200) 범위의 인덱스 갭에 락을 걸어
  → 이 범위에 새 행 INSERT 불가

인덱스 값: 10, 20, 30

Next-Key Lock 범위
  (-∞, 10]  → 레코드 10 + 이전 갭
  (10, 20]  → 레코드 20 + 이전 갭
  (20, 30]  → 레코드 30 + 이전 갭
  (30, +∞)  → supremum + 이전 갭

SELECT * FROM t WHERE val = 20 FOR UPDATE;
  → (10, 20] 범위에 Next-Key Lock
  → (20, 30) 범위에 Gap Lock
  → val = 15, 25 등의 INSERT 차단

T1 (REPEATABLE READ)           T2 (REPEATABLE READ)
───                            ───
BEGIN                          BEGIN
SELECT 잔고 FROM 계좌 → 100
                               SELECT 잔고 FROM 계좌 → 100
UPDATE 계좌 SET 잔고 = 90
                               UPDATE 계좌 SET 잔고 = 80
COMMIT (성공)
                               COMMIT → ERROR: could not serialize access
                               → T2는 ROLLBACK 후 재시도 필요

MySQL InnoDB:
  → 모든 SELECT가 자동으로 SELECT ... FOR SHARE로 변환
  → 공유 락이 걸려 쓰기를 차단
  → 락 기반 직렬화 (Pessimistic)

PostgreSQL:
  → SSI(Serializable Snapshot Isolation) 사용
  → 락 없이 스냅샷 기반으로 동작
  → 커밋 시점에 직렬화 위반 여부 검사
  → 충돌 시 serialization failure 오류 → ROLLBACK 후 재시도
  → 낙관적(Optimistic) 접근

Oracle:
  → 내부적으로 SCN 기반 스냅샷 사용
  → 쓰기 충돌 시 ORA-08177: can't serialize access 발생
  → READ COMMITTED + SELECT ... FOR UPDATE 조합을 더 많이 사용

데이터 행: id=1, name='Alice', salary=300

T1이 UPDATE salary=400 실행
  → 현재 버전(salary=300)을 Undo 영역에 보존
  → 새 버전(salary=400)을 생성

T2가 SELECT *
  → T2의 격리 수준과 시작 시점에 따라 적절한 버전을 선택
  → READ COMMITTED: 가장 최근 커밋된 버전
  → REPEATABLE READ: 트랜잭션 시작 시점의 버전

핵심: 읽기가 쓰기를 차단하지 않음! (락 없이 읽기)

ReadView 생성 시 기록
  1. creator_trx_id: 이 ReadView를 만든 트랜잭션 ID
  2. m_ids: 현재 활성 트랜잭션 ID 목록
  3. m_low_limit_id: 다음에 할당될 트랜잭션 ID (상한)
  4. m_up_limit_id: 활성 트랜잭션 중 가장 작은 ID (하한)

가시성 판단
  행의 trx_id < m_up_limit_id → 커밋된 버전, 보임
  행의 trx_id >= m_low_limit_id → 미래 트랜잭션, 안 보임
  행의 trx_id in m_ids → 활성 트랜잭션, 안 보임
  그 외 → 커밋된 버전, 보임

READ COMMITTED: 매 SELECT마다 새 ReadView 생성
REPEATABLE READ: 첫 SELECT 시 한 번만 ReadView 생성 → 재사용

데이터 정합성이 생명보다 중요한가?
├─ YES → SERIALIZABLE (금융, 의료 등)
└─ NO → 트랜잭션 내에서 같은 데이터를 여러 번 읽는가?
         ├─ YES → REPEATABLE READ
         └─ NO → READ COMMITTED (대부분의 경우)

READ UNCOMMITTED
  → 락 없이 읽기 → 최고 처리량
  → 데이터 정합성 보장 불가

READ COMMITTED
  → 읽기 시 공유 락 즉시 해제 (또는 MVCC로 락 없이)
  → 높은 처리량, 적절한 정합성

REPEATABLE READ
  → 읽기 락 트랜잭션 종료까지 유지 (또는 MVCC 스냅샷)
  → InnoDB: Gap Lock 추가로 인한 INSERT 대기 발생 가능
  → 중간 처리량

SERIALIZABLE
  → 모든 읽기에 공유 락 또는 직렬화 검증
  → 가장 낮은 처리량
  → 재시도 로직 필수 (직렬화 실패 대응)