MVCC란 무엇이며 갭 잠금 장치는 왜 설계됩니까?

이 기사에서는 MVCC를 이해하고, MVCC와 격리 수준의 관계를 소개하고, 설계 관점에서 MVCC가 설계된 이유와 RC와 RR의 격리 수준의 차이점에 대해 설명합니다.

MVCC의 역할

MVCC를 사용하면 행 잠금을 지원하는 대부분의 트랜잭션 엔진이 더 이상 데이터베이스 동시성 제어를 위해 행 잠금을 사용하지 않고 비잠금 읽기와 데이터베이스 행 잠금을 결합할 수 있습니다. 매우 적은 오버헤드로 달성할 수 있습니다. 따라서 데이터베이스의 동시성 성능이 향상됩니다.

MVCC는 잠금 없는 방식으로 읽기-쓰기 충돌 문제를 해결합니다. 여기서의 읽기는 스냅샷 읽기를 의미합니다. 즉, MVCC에서 구현한 스냅샷 읽기! ! !

MVCC란 무엇입니까

다중 버전 동시성 제어(MVCC)는 읽기-쓰기 충돌을 해결하는 잠금 없는 동시성 제어입니다.

기록의 각 행에는 생성 버전 번호와 롤백 포인터라는 두 개의 숨겨진 열이 있습니다. 트랜잭션이 시작된 후 트랜잭션 ID가 있습니다. 여러 동시 트랜잭션이 특정 행을 동시에 작동합니다. 행에 대한 서로 다른 트랜잭션의 업데이트 작업은 여러 버전을 생성한 다음 롤백 포인터를 사용하여 실행 취소 로그 체인을 형성합니다. MVCC의 스냅샷 읽기는 트랜잭션 ID와 생성 버전 번호를 통해 이루어집니다.

MVCC와 격리 수준의 관계

MVCC는 읽기-쓰기 문제를 해결하는 것입니다. 그리고 다양한 구성을 통해 트랜잭션이 시작된 후 스냅샷을 반복해서 읽을 수 없는 문제도 해결할 수 있습니다.

• 반복 불가능 읽기: 동일한 트랜잭션에서 읽은 일부 데이터가 변경되었거나 일부 기록이 삭제되었습니다.

• 팬텀 읽기(Phantom reading): 한 트랜잭션이 이전에 검색한 데이터를 동일한 쿼리 조건에 따라 다시 읽었지만, 다른 트랜잭션에서 쿼리 조건에 맞는 새 데이터를 삽입했음을 발견하는 현상을 팬텀 읽기라고 합니다.

RC와 RR 모두 MVCC를 구현하는데 왜 RR이 RC의 반복 불가능한 읽기 문제를 해결합니까?

RC에 반복읽기가 불가능한 문제가 발생하는 이유는 단지 개발자가 의도적으로 설정했기 때문이라고 생각하시면 됩니다(격리 수준을 여러개 설정하면 사용자가 상황에 따라 설정 가능). 원래는 데이터베이스에 데이터가 제출되어 있어서 RC에서 읽어도 문제가 없나요? 또한 Oracle 데이터베이스 자체의 격리 수준은 RC입니다.

READ-COMMITTED (Read Committed)

Read Committed RC. 이 격리 수준에서는 SQL 수준에서 일관된 읽기가 가능하며 각 SQL 문은 새로운 ReadView를 생성합니다. 이는 두 쿼리 사이에 다른 트랜잭션이 제출되었으며 일관되지 않은 데이터를 읽을 수 있음을 의미합니다.

REPEATABLE-READ (Repeatable Read)

Repeatable Read RR, ReadView가 처음 생성된 후 이 ReadView는 트랜잭션이 끝날 때까지 유지됩니다. 즉, 실행 중에 가시성이 변경되지 않습니다. 트랜잭션 내에서 반복 가능한 읽기를 달성합니다.

MVCC 및 gap lock

MVCC 잠금 프리는 읽기-쓰기 충돌 문제를 해결합니다. 그리고 반복 불가능한 읽기 문제를 해결합니다. 이는 RC와 RR의 두 가지 격리 수준을 달성합니다.

그리고

gap lock은 여전히 ​​기본적으로 두 개의 동시 트랜잭션 실행을 차단하는 잠금입니다.

그럼 RR이 갭락에 들어가는 이유는 단지 팬텀리딩의 문제를 해결하기 위함인가요?

注意：只有RR隔离级别才存在间隙锁。

Gap lock은 환상 읽기 문제를 어느 정도 해결할 수 있지만, gap lock의 도입은 binlog의 문 모드에서 버그를 처리하는 데 더 가깝다고 생각합니다.

mysql 데이터베이스의 마스터-슬레이브 복제는 binlog에 의존합니다. mysql5.0 이전에는 binlog 모드에는 명령문 형식만 있었습니다. 이 모드의 특징은 binlog의 기록 순서가 데이터베이스 트랜잭션 커밋 순서대로 기록된다는 것입니다.

갭 잠금이 없는 경우 다음과 같은 시나리오가 발생합니다. 마스터 라이브러리에는 다음 두 가지 트랜잭션이 있습니다.

1 먼저 삭제 ID 이때 binlog에 기록되는 로그는 다음과 같습니다. 트랜잭션 b가 먼저 실행되고, 트랜잭션 a가 실행됩니다(binlog에 커밋 순서가 기록됩니다).
그럼 메인 라이브러리 이때 테이블에 id=3인 레코드가 있는데, 슬레이브 데이터베이스가 먼저 삽입된 후 삭제되고, 슬레이브 데이터베이스에는 레코드가 없습니다.

이로 인해 마스터와 슬레이브 데이터 간의 불일치가 발생합니다.

이 버그를 해결하기 위해 RR 레벨에서는 Gap Lock이 도입되었습니다.

【관련 추천:

mysql 비디오 튜토리얼

】

위 내용은 MVCC란 무엇이며 갭 잠금 장치는 왜 설계됩니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!