MVCC implementation map

세 엔진 모두 스냅샷을 읽지만, 과거 버전을 둔 위치가 운영 리스크를 다르게 만듭니다.

MVCC 비교는 기능 이름보다 “현재 행에서 과거 버전까지 어떻게 되돌아가는가”를 먼저 보면 이해가 쉽습니다.

읽기 비차단은 공통 차이는 버전 저장 위치, 가시성 판정 기준, 정리 지연이 남기는 흔적입니다.
엔진
과거 버전 위치
보이는 버전 판단
정리 지연의 증상
Oracle Undo Segment + SCN
테이블 밖 Undo를 따라 복원 현재 블록이 조회 시점보다 최신이면 undo를 거슬러 필요한 버전을 재구성합니다.
쿼리 시작 SCN 기준 SCN보다 늦은 변경은 감추고, 시작 시점의 일관된 모습을 보여 줍니다.
Undo 보존 실패 오래 열린 읽기가 필요한 undo를 잃으면 ORA-01555처럼 스냅샷 복원이 깨질 수 있습니다.
MySQL InnoDB Undo Log + Read View
최신 행에서 Undo Log로 되감기 레코드에 연결된 이력을 따라 읽을 수 있는 이전 버전을 찾습니다.
TRX_ID와 Read View 범위 활성 트랜잭션 목록과 ID 범위로 이 버전이 스냅샷 안에 있는지 판단합니다.
Purge 지연 긴 트랜잭션이 정리를 막으면 undo가 비대해지고 공간·정리 부하가 커집니다.
PostgreSQL Heap Tuple + VACUUM
같은 테이블 안에 새 튜플 누적 UPDATE는 기존 행을 덮지 않고 새 튜플을 만들며, 예전 튜플은 나중에 회수합니다.
xmin/xmax와 커밋 상태 생성·삭제 트랜잭션 ID와 커밋 여부로 현재 스냅샷에 보일지 정합니다.
VACUUM 지연과 bloat dead tuple 회수가 늦으면 테이블과 인덱스가 불어나 읽기 효율까지 떨어집니다.
실무 해석

Oracle은 undo 보존, InnoDB는 purge 지연, PostgreSQL은 VACUUM과 bloat를 먼저 봅니다. 같은 MVCC라도 병목 신호는 엔진마다 다르게 나타납니다.