- 한 트랜잭션 내에 동일한 쿼리를 2번 이상 보냈을때 그 조회 결과가 다름
- Read 에 관한 문제구나, 삽입 삭제 이런거랑은 무관하게 생각해보자
- 귀신이 데이터를 변경했네?? ㅎㄷㅎㄷ
- 다른 트랜잭션에서 새로운 레코드 삽입함으로써 팬텀리드가 발생할 수 있음
- Tx A가 특정 조건(balance >= 1000)을 만족하는 계좌 목록을 조회
- Tx B가 새 계좌를 추가(잔액 2000만원)하고 커밋
- Tx A가 다시 조회하면 처음에는 없던 계좌가 새롭게 나타남 → 팬텀 리드
“팬텀 리드”란, 트랜잭션 도중 **새로운 행**이 삽입되어, **같은 WHERE 조건으로 다시 조회했을 때 결과 집합이 달라지는** 현상을 말합니다.
하지만 MySQL의 MVCC(`REPEATABLE READ`)에서는, **트랜잭션 시작 시점**(혹은 첫 SELECT 시점)의 스냅샷(딩코-1)을 계속 참조하기 때문에, 중간에 Insert된 새로운 버전(딩코-2)을 **다른 세션**(Session B)에서 보는 것을 기본적으로 차단합니다.
즉, B 입장에서는 **새로 삽입된 레코드가 아예 없는 것처럼** 인식하여, 다시 조회해도 결과 집합이 변하지 않으므로 **팬텀 리드가 발생하지 않습니다**.
문제 상황(유령 데이터 문제)
예시: 재고 수량이 늘면서 ‘조기 품절 보상’을 못 받게 된 경우
- 쇼핑몰에서 “재고가 1개 남았다”고 조회
- “금방 품절될 테니, 품절 시 제공되는 대체 상품 보상(또는 쿠폰)을 기해하고 있었다”
- 그런데 갑자기 판매자가 새 물량 5개 추가 입고함
- 다시 확인해보니 재고가 6개로 늘어나 있어, 품절 보상 대상에서 제외됨
팬텀 리드는 단순히 레코드가 증가하는 상황만 의미한는게 아님
중요한건 트랜잭션(또는 같은 세션)도중, 새로 삽입된(또는 삭제된) 데이터 때문에 “같은 조건의 재조회 결과”가 달라져 버린다는 점
이로 인해 사용자나 운영 주체가 잘못된 의사결정이나 혜택을 놓치거나, 정산/집계 오류가 일어날 수 있다는 것이 ‘문제’
즉, “처음 본 정보가 확정값인줄 알았는데, 중간에 새 데이터 추가됨으로서 완전히 다른 결과가 나온다”는 데서 업무적, 금전적, 시간적 손실이 발생할 수 있는게 팬텀 리드의 위험성
허용 가능한 도메인
은행 계좌 조회
- 계좌 잔액 여러번 조회해도 같은 값 나와야됨
- 조회하다가 추가적인 입금 내역 나와도 노상관 온라인 게임 랭킹 시스템
- 내 점수가 조회할 때 마다 바뀌면 안됨. 그런데 새로운 계정은 맘대로 추가되어도 됨
부적합 도메인
계좌 개설 시 중복 검사
로직에 영향을 주는 경우…흠 애매하게 이해는 됨