공통 원인 엔진 구현은 달라도 병목은 같다. 오래 열린 트랜잭션이 버전 정리를 늦춘다.

MVCC 비용의 핵심은
버전을 오래 붙잡는 시간입니다

이전 버전을 남기는 것 자체가 문제가 아니라, 정리 가능한 시점이 뒤로 밀릴 때 저장 공간과 읽기 추적 비용이 함께 커집니다. 그래서 성능 관점에서는 기능 이름보다 어디에 쌓이고, 누가 치우며, 지연되면 무엇이 느려지는지를 봐야 합니다.

1단계
긴 트랜잭션 유지
오래된 스냅샷을 계속 참조
2단계
정리 기준점 정체
Purge·VACUUM·Undo 재사용 지연
3단계
이전 버전 누적
버전 체인 또는 dead tuple 증가
4단계
읽기·저장 비용 동시 상승
조회 추적 증가, 공간 회수 지연
같은 질문으로 비교
Oracle
MySQL InnoDB
PostgreSQL
이전 버전이 남는 자리
Undo Tablespace

수정 전 이미지가 Undo 세그먼트에 남아 읽기 일관성을 유지합니다.

Undo Log

행 버전 정보가 Undo 체인으로 이어져 이전 상태를 따라가게 합니다.

테이블 내부 dead tuple

오래된 튜플이 테이블과 인덱스 안에 남아 새 버전과 함께 공존합니다.

누가 정리하나
Undo 재사용 시점

더 이상 참조되지 않는 버전부터 공간을 회수합니다.

Purge Thread

불필요해진 Undo 레코드를 뒤에서 천천히 제거합니다.

VACUUM

보이지 않는 튜플을 정리하고 재사용 가능한 공간으로 돌려놓습니다.

지연되면 먼저 보이는 신호
Undo 사용량 확대

오래된 읽기를 보존하느라 Undo 공간 압박이 커집니다.

History list 증가

버전 체인이 길어져 SELECT가 더 많은 Undo를 추적합니다.

Table bloat

dead tuple이 쌓여 테이블과 인덱스 스캔 부담이 커집니다.

운영에서 볼 것

공통 대응은 긴 트랜잭션을 줄이는 것이고, 엔진별 관찰 지표는 다릅니다. Oracle은 Undo 사용량, MySQL은 purge 지연과 history list, PostgreSQL은 VACUUM 지연과 bloat를 보면 MVCC 비용이 어디서 커지는지 바로 읽을 수 있습니다.