잠금 기반은 현재 데이터를 직접 보호하고, MVCC는 과거 버전을 남겨 읽기와 쓰기를 분리합니다. 그래서 같은 격리 수준 이름이라도 실제 체감 동작은 DBMS마다 달라집니다.
이 표는 “누가 더 좋다”가 아니라, 읽기-쓰기 충돌을 어떤 방식으로 처리하는가를 기준으로 DBMS를 배치한 구조입니다.
| 비교 질문 | 잠금 기반 현재 행이나 범위를 직접 보호 | MVCC 버전을 남겨 스냅샷으로 읽기 |
|---|---|---|
|
읽는 순간 무엇을 보나?
조회가 쓰기와 만났을 때의 기본 감각
|
현재 값을 그대로 읽되, 필요하면 잠금 때문에 기다립니다.읽기가 보호된 행이나 범위와 충돌하면 대기나 차단이 먼저 드러납니다. 읽기 일관성은 잠금 규칙으로 확보합니다. |
자기 트랜잭션 시점의 버전을 읽습니다.동시에 다른 트랜잭션이 값을 바꿔도, 조회는 자신이 시작했을 때 보이던 버전을 계속 읽습니다. 읽기와 쓰기가 직접 부딪히는 일이 줄어듭니다. |
|
충돌은 어디서 처리하나?
무엇을 대가로 일관성을 지키는가
|
읽기-쓰기 충돌
잠금 대기, 차단, 범위 잠금으로 직접 제어합니다.
운영 의미
정책은 단순하지만, 읽기 부하가 높으면 대기 시간이 눈에 띄기 쉽습니다. |
읽기-쓰기 분리
읽기는 과거 버전을 보고, 쓰기끼리의 충돌만 별도로 조정합니다.
운영 의미
동시성은 높지만, 오래된 버전을 정리하는 Vacuum/Purge 비용이 생깁니다. |
|
대표적으로 어디에 놓이나?
실제 DBMS를 전략 위에 배치
|
SQL Server 기본 동작기본 철학은 잠금 중심입니다. 조회도 잠금 정책의 영향을 받으며, 필요할 때 SNAPSHOT 옵션을 별도로 켭니다.
SQL Server
기본 READ COMMITTED
|
PostgreSQL·Oracle은 MVCC가 기본조회는 잠금보다 스냅샷 읽기가 먼저입니다. MySQL(InnoDB)도 기본 조회는 MVCC를 쓰지만, 팬텀 방지를 위해 범위 잠금을 적극 결합합니다.
PostgreSQL
Oracle
MySQL InnoDB
|
정리: 현대 DBMS의 큰 흐름은 읽기를 잠그기보다 버전으로 분리하는 쪽으로 이동했습니다. 그래서 바로 다음 MVCC 절에서는 “왜 읽는 동안 써도 되는가”를 버전 체인과 스냅샷 관점에서 이해하면 됩니다.