MVCC 비교

읽기는 과거를 보지만, 과거를 두는 곳은 DBMS마다 다르다

세 엔진 모두 읽기 일관성을 지키려는 목표는 같지만, 이전 버전을 어디에 저장하고 어떤 기준으로 꺼내 보는지가 달라서 운영 포인트도 달라진다.

공통 목표

쓰기와 읽기를 직접 막아 세우지 않고, 각 조회가 볼 수 있는 시점의 버전을 안정적으로 선택한다.

같은 질문으로 비교
Oracle Undo 중심으로 과거 복원
MySQL ReadView와 undo를 함께 사용
PostgreSQL 행 자체에 버전 정보를 보관
과거 버전 위치
Undo Segment / Tablespace

현재 블록을 읽되, 필요하면 undo로 되돌린 시점을 만든다.

Undo Log + Rollback Segment

최신 레코드 뒤에 undo 체인을 따라가며 보이는 버전을 찾는다.

Heap Tuple 안의 다중 버전

기본 테이블 안에 이전·현재 버전이 함께 남아 있다.

읽기 기준
SCN

조회가 요청한 시점의 시스템 변경 번호에 맞는 버전을 선택한다.

Transaction ID + ReadView

trx_id를 스냅샷 경계와 대조해 가시성을 판정한다.

xmin / xmax

행을 만든 트랜잭션과 지운 트랜잭션의 ID로 보임 여부를 정한다.

오래된 버전 정리
Undo Retention 이후 자동 회수

필요 기간이 지나면 undo 공간이 재사용된다.

Purge Thread

더 이상 어떤 ReadView에도 필요 없는 undo를 뒤에서 치운다.

VACUUM

죽은 tuple을 청소하고 테이블 비대화를 완화한다.

읽기 일관성 감각
문장 단위에서 특히 강함

기본적으로 각 문장이 자기 시점의 일관된 데이터를 본다.

트랜잭션 시작 스냅샷 유지

같은 트랜잭션 안의 반복 조회가 같은 시점을 오래 본다.

문장 / 트랜잭션 단위 선택

격리 수준에 따라 스냅샷의 유지 범위가 달라진다.

운영에서 먼저 보게 되는 차이

저장 위치가 곧 관리 포인트다
Oracle

긴 조회가 많으면 undo 보존량이 읽기 안정성의 안전선이 된다.

MySQL

ReadView가 유지되는 동안 purge가 늦어질 수 있어 snapshot과 정리 속도를 함께 본다.

PostgreSQL

VACUUM이 늦으면 dead tuple이 쌓여 저장 공간과 성능 부담으로 이어진다.