MySQL의 기본 -2

InnoDB의 MVCC와 일관된 읽기

InnoDB는 MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어)를 통해, 여러 트랜잭션이 동시에 안전하게 데이터를 읽고 쓸 수 있도록 보장합니다. 이 방식에서는 한 레코드에 대해 여러 버전의 데이터가 언두 로그(Undo Log)에 보관되어, 각각의 트랜잭션이 일관된 데이터를 볼 수 있게 해줍니다.

데이터 버전 관리와 격리 수준에 따른 조회

UPDATE와 같은 변경 쿼리가 실행되면, InnoDB는 커밋 여부와 무관하게 버퍼 풀(Buffer Pool)에서 데이터를 갱신합니다. 데이터 파일(디스크)은 Write 스레드나 체크포인트 시점에만 동기화될 수 있으며, ACID 보장을 위해 일반적으로 버퍼 풀과 데이터 파일의 상태가 일치한다고 봐도 무방합니다.

트랜잭션의 격리 수준(Isolation Level)에 따라 읽는 데이터가 달라집니다.

(1) READ UNCOMMITTED : 아직 커밋되지 않은 변경 내용도 즉시 볼 수 있습니다(Dirty Read 허용). 이때 InnoDB는 버퍼 풀에 있는 최신 데이터를 바로 반환합니다.

(2) READ COMMITTED, REPEATABLE READ, SERIALIZABLE: 커밋되지 않은 변경은 노출되지 않습니다. InnoDB는 언두 로그에 남아 있는, 트랜잭션이 시작할 당시의 일관된 데이터 버전을 반환합니다.

잠금 없는 일관된 읽기(Consistent Non-Locking Read)

MVCC 덕분에 InnoDB는 대부분의 SELECT(읽기) 작업에서 잠금 없이 일관된 읽기를 제공합니다. 즉, 순수 SELECT 쿼리는 다른 트랜잭션의 잠금에 대기하지 않고 항상 즉시 실행될 수 있습니다. 단, 격리 수준이 SERIALIZABLE이 아닐 경우에 해당합니다. 이 과정에서 InnoDB는 변경 전의 데이터를 제공하기 위해 Undo 로그를 적극적으로 활용합니다.

오래 지속되는 트랜잭션과 언두 로그 관리

MVCC 구조상, 활성 트랜잭션이 오래 지속되면 언두 로그가 삭제되지 않고 계속 유지되어야 합니다. 이는 스냅샷 일관성(Snapshot Consistency)을 보장하기 위함이지만, 언두 로그가 지속적으로 쌓이면 디스크 사용량이 급증하고, 퍼포먼스 저하 및 락 경합, 메모리 압박 등이 발생할 수 있습니다.

실무에서 주의할 점

트랜잭션을 불필요하게 오래 열어두면 언두 로그가 계속 증가하여, 시스템 전반에 성능 저하·슬로우 쿼리·디스크 부족 등 다양한 문제를 일으킬 수 있습니다. 따라서, 트랜잭션은 가능한 한 짧게 유지하며, 작업이 끝나면 즉시 COMMIT 또는 ROLLBACK으로 마무리하는 것이 중요합니다.

자동 데드락 감지 기능

InnoDB는 자동 데드락 감지(Deadlock Detection) 기능을 제공합니다. 데드락 상황이 발생하면, InnoDB가 언두 로그가 적은(즉, 롤백 비용이 적은) 트랜잭션을 강제로 중단시켜 데드락을 해소합니다. 이러한 자동 감지·회수 기능 덕분에, 개발자는 복잡한 트랜잭션 충돌 상황에서도 안정적으로 시스템을 운영할 수 있습니다.