[MySQL] 다중 버전 동시성 제어

MySQL에서 대부분의 트랜잭션 스토리지 엔진 구현은 단순한 행 수준 잠금이 아닙니다. 동시성 성능 향상을 고려하여 MVCC(다중 버전 동시성 제어)를 동시에 구현하는 것이 일반적입니다. MySQL뿐만 아니라 Oracle, PostgreSQL 등 다른 데이터베이스 시스템도 MVCC를 구현하지만 MVCC에 대한 통일된 표준이 없기 때문에 구현 메커니즘이 다릅니다.

MVCC는 행 수준 잠금의 변형이라고 생각할 수 있지만 많은 경우 잠금 작업을 피하므로 오버헤드가 더 낮습니다. 구현 메커니즘은 다르지만 대부분은 비차단 읽기 작업을 구현하고 쓰기 작업은 필요한 행만 잠급니다.

MVCC는 특정 시점의 데이터를 스냅샷으로 저장하는 방식으로 구현됩니다. 즉, 실행하는 데 시간이 얼마나 걸리더라도 각 트랜잭션에서 표시되는 데이터는 일관됩니다. 트랜잭션이 시작되는 시간에 따라 동일한 테이블에 있는 각 트랜잭션이 동시에 보는 데이터는 다를 수 있습니다.

다양한 스토리지 엔진의 MVCC 구현은 다르며 일반적으로 낙관적 동시성 제어와 비관적 동시성 제어가 있습니다. 아래에서는 InnoDB 동작의 단순화된 버전을 통해 MVCC가 어떻게 작동하는지 보여줍니다.

InnoDB의 MVCC는 각 레코드 행 뒤에 두 개의 숨겨진 열을 저장하여 구현됩니다. 이 두 열 중 하나는 행의 생성 시간을 보유하고 다른 하나는 행의 만료 시간(또는 삭제 시간)을 보유합니다. 물론 저장되는 것은 실제 시간 값이 아니라 시스템 버전 번호이다. 새로운 트랜잭션이 시작될 때마다 시스템 버전 번호가 자동으로 증가됩니다. 사무. 트랜잭션 시작 시 시스템 버전 번호는 쿼리된 각 레코드 행의 버전 번호와 비교하는 데 사용되는 트랜잭션 버전 번호로 사용됩니다. REPEATABLE READ 격리 수준에서 MVCC가 어떻게 작동하는지 살펴보겠습니다.

SELECT

InnoDB는 다음 두 가지 조건에 따라 레코드의 각 행을 확인합니다.

• InnoDB는 버전 번호가 이전인 데이터 행만 찾습니다. 즉, 행의 시스템 버전 번호가 트랜잭션보다 작거나 같습니다. 이렇게 하면 트랜잭션이 읽은 행이 트랜잭션이 시작되기 전에 이미 존재했거나 트랜잭션에 의해 삽입 또는 수정되었는지 확인됩니다. 거래 자체.

• 행의 삭제된 버전이 정의되지 않았거나 현재 트랜잭션 버전 번호보다 큽니다. 이렇게 하면 트랜잭션이 읽은 행이 트랜잭션이 시작되기 전에 삭제되지 않았음을 보장합니다.

위 두 조건을 모두 만족하는 레코드만 쿼리 결과로 반환될 수 있습니다.

INSERT

InnoDB는 현재 시스템 버전 번호를 삽입된 각 행의 행 버전 번호로 저장합니다.

DELETE

InnoDB는 현재 시스템 버전 번호를 삭제된 각 행의 행 삭제 식별자로 저장합니다.

UPDATE

InnoDB는 새 레코드 행을 삽입하고 현재 시스템 버전 번호를 행 버전 번호로 저장하며 현재 시스템 버전 번호를 행 삭제 식별자로 원래 행에 저장합니다.

대부분의 데이터 읽기 작업을 잠그지 않고 수행할 수 있도록 이 두 개의 추가 시스템 버전 번호를 저장하십시오. 이 디자인은 데이터 읽기 작업을 매우 간단하게 만들고 성능도 매우 좋으며 표준을 충족하는 행만 읽도록 보장합니다. 단점은 각 레코드 행에 추가 저장 공간, 더 많은 확인 및 일부 추가 유지 관리가 필요하다는 것입니다.

MVCC는 REPEATABLE READ와 READ COMMITTED라는 두 가지 격리 수준에서만 작동합니다. 다른 두 격리 수준은 READ UNCOMMITTED가 항상 현재 트랜잭션 버전을 따르는 데이터 행이 아닌 최신 데이터 행을 읽기 때문에 MVCC와 호환되지 않습니다. SERIALIZABLE은 읽은 모든 행을 잠급니다.

참고: MVCC에는 공식적인 사양이 없으므로 각 스토리지 엔진 및 데이터베이스 시스템의 구현이 다릅니다. 그 누구도 다른 방법이 틀렸다고 말할 수 없습니다.

MySQL에서 대부분의 트랜잭션 스토리지 엔진 구현은 단순한 행 수준 잠금이 아닙니다. 동시성 성능 향상을 고려하여 MVCC(다중 버전 동시성 제어)를 동시에 구현하는 것이 일반적입니다. MySQL뿐만 아니라 Oracle, PostgreSQL 등 다른 데이터베이스 시스템도 MVCC를 구현하지만 MVCC에 대한 통일된 표준이 없기 때문에 구현 메커니즘이 다릅니다.

MVCC는 행 수준 잠금의 변형이라고 생각할 수 있지만 많은 경우 잠금 작업을 피하므로 오버헤드가 더 낮습니다. 구현 메커니즘은 다르지만 대부분은 비차단 읽기 작업을 구현하고 쓰기 작업은 필요한 행만 잠급니다.

MVCC는 특정 시점의 데이터를 스냅샷으로 저장하는 방식으로 구현됩니다. 즉, 실행하는 데 시간이 얼마나 걸리더라도 각 트랜잭션에 표시되는 데이터는 일관됩니다. 트랜잭션이 시작되는 시간에 따라 동일한 테이블에 있는 각 트랜잭션이 동시에 보는 데이터는 다를 수 있습니다.

다양한 스토리지 엔진의 MVCC 구현은 다르며 일반적으로 낙관적 동시성 제어와 비관적 동시성 제어가 있습니다. 아래에서는 InnoDB 동작의 단순화된 버전을 통해 MVCC가 어떻게 작동하는지 보여줍니다.

InnoDB의 MVCC는 각 레코드 행 뒤에 두 개의 숨겨진 열을 저장하여 구현됩니다. 이 두 열 중 하나는 행의 생성 시간을 보유하고 다른 하나는 행의 만료 시간(또는 삭제 시간)을 보유합니다. 물론 저장되는 것은 실제 시간 값이 아니라 시스템 버전 번호이다. 새로운 트랜잭션이 시작될 때마다 시스템 버전 번호가 자동으로 증가됩니다. 사무. 트랜잭션 시작 시 시스템 버전 번호는 쿼리된 각 레코드 행의 버전 번호와 비교하는 데 사용되는 트랜잭션 버전 번호로 사용됩니다. REPEATABLE READ 격리 수준에서 MVCC가 어떻게 작동하는지 살펴보겠습니다.

SELECT

InnoDB는 다음 두 가지 조건에 따라 레코드의 각 행을 확인합니다.

• InnoDB는 버전 번호가 이전인 데이터 행만 찾습니다. 즉, 행의 시스템 버전 번호가 트랜잭션보다 작거나 같습니다. 이렇게 하면 트랜잭션이 읽은 행이 트랜잭션이 시작되기 전에 이미 존재했거나 트랜잭션에 의해 삽입 또는 수정되었는지 확인됩니다. 거래 자체.

• 행의 삭제된 버전이 정의되지 않았거나 현재 트랜잭션 버전 번호보다 큽니다. 이렇게 하면 트랜잭션이 읽은 행이 트랜잭션이 시작되기 전에 삭제되지 않았음을 보장합니다.

위 두 조건을 모두 만족하는 레코드만 쿼리 결과로 반환될 수 있습니다.

INSERT

InnoDB는 현재 시스템 버전 번호를 삽입된 각 행의 행 버전 번호로 저장합니다.

DELETE

InnoDB는 현재 시스템 버전 번호를 삭제된 각 행의 행 삭제 식별자로 저장합니다.

UPDATE

InnoDB는 새 레코드 행을 삽입하고 현재 시스템 버전 번호를 행 버전 번호로 저장하며 현재 시스템 버전 번호를 행 삭제 식별자로 원래 행에 저장합니다.

대부분의 데이터 읽기 작업을 잠그지 않고 수행할 수 있도록 이 두 개의 추가 시스템 버전 번호를 저장하십시오. 이 디자인은 데이터 읽기 작업을 매우 간단하게 만들고 성능도 매우 좋으며 표준을 충족하는 행만 읽도록 보장합니다. 단점은 각 레코드 행에 추가 저장 공간, 더 많은 확인 및 일부 추가 유지 관리가 필요하다는 것입니다.

MVCC는 REPEATABLE READ와 READ COMMITTED라는 두 가지 격리 수준에서만 작동합니다. 다른 두 격리 수준은 READ UNCOMMITTED가 항상 현재 트랜잭션 버전을 따르는 데이터 행이 아닌 최신 데이터 행을 읽기 때문에 MVCC와 호환되지 않습니다. SERIALIZABLE은 읽은 모든 행을 잠급니다.

참고: MVCC에는 공식적인 사양이 없으므로 각 스토리지 엔진 및 데이터베이스 시스템의 구현이 다릅니다. 그 누구도 다른 방법이 틀렸다고 말할 수 없습니다.

위 내용은 [MySQL] 다중 버전 동시성 제어 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(m.sbmmt.com)를 참고해주세요!