MVCC는 Multi-Version Concurrency Control의 약자로, 주로 데이터베이스의 동시성 성능을 향상시키기 위한 다중 버전 동시성 제어입니다. 동일한 데이터 행에 대해 읽기 또는 쓰기 요청이 발생하면 해당 행이 잠겨 차단됩니다. MVCC는 읽기 및 쓰기 요청을 처리하기 위해 보다 최적화된 방법을 사용하며, 잠금 없이 읽기 및 쓰기 요청 충돌을 처리할 수 있습니다. 이는 비관적 잠금 메커니즘인 현재 읽기가 아닌 스냅샷 읽기를 나타냅니다. 다음 연구에서는 잠금 없이 읽기 및 쓰기 작업을 수행하는 방법을 배우고 스냅샷 읽기 및 현재 읽기의 개념도 분석합니다.
MySQL은 REPEATABLE READ 격리 수준에서 팬텀 읽기 문제를 대부분 방지할 수 있습니다. MySQL은 이를 어떻게 수행합니까?
버전 체인
우리는 InnoDB 스토리지 엔진을 사용하는 테이블의 경우 클러스터형 인덱스 레코드에 두 개의 필수 숨겨진 열이 포함되어 있음을 알고 있습니다(row_id는 필요하지 않으며, 우리가 만든 테이블에는 기본 키가 있거나 NULL이 아닌 UNIQUE 키가 있음) row_id 열은 포함하지 않음):
trx_id: 트랜잭션이 클러스터형 인덱스 레코드를 변경할 때마다 트랜잭션의 트랜잭션 ID가 trx_id 숨겨진 열에 할당됩니다.
roll_pointer: 클러스터형 인덱스 레코드가 수정될 때마다 이전 버전이 실행 취소 로그에 기록됩니다. 그러면 이 숨겨진 열은 수정 전 레코드를 찾는 데 사용할 수 있는 포인터와 같습니다.
对该记录每次更新后,都会将旧值放到一条undo日志中,就算是该记录的一个旧版本,随着更新次数的增多,所有的版本都会被roll_pointer属性连接成一个链表,我们把这个链表称之为版本链,版本链的头节点就是当前记录最新的值。另外,每个版本中还包含生成该版本时对应的事务id。于是可以利用这个记录的版本链来控制并发事务访问相同记录的行为,那么这种机制就被称之为多版本并发控制(Mulit-Version Concurrency Control MVCC)。
# Transaction 80
set session transaction isolation level read committed;
begin
update teacher set name='S' where number=1;
update teacher set name='T' where number=1;
로그인 후 복사
此刻,表teacher中number为1的记录得到的版本链表如下所示:
假设现在有一个使用READ COMMITTED隔离级别的事务开始执行:
set session transaction isolation level read committed;
# 使用READ COMMITTED隔离级别的事务
begin;
# SELECE1:Transaction 80、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
set session transaction isolation level read committed;
# Transaction 120
begin
update teacher set name='K' where number=1;
update teacher set name='F' where number=1;
# 使用READ COMMITTED隔离级别的事务
begin;
# SELECE1:Transaction 80、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
# SELECE2:Transaction 80提交、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'T'
# 使用REPEATABLE READ隔离级别的事务
begin;
# SELECE1:Transaction 80、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
# SELECE2:Transaction 80提交、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
뭐야, 무슨 일이야? 트랜잭션 T1에는 분명히 팬텀 읽기 현상이 있습니다. REPEATABLE READ 격리 수준에서 T1은 처음으로 일반 SELECT 문을 실행할 때 ReadView를 생성한 다음 T2는 Teacher 테이블에 새 레코드를 삽입하고 제출합니다. ReadView는 T1이 새로 삽입된 레코드를 수정하기 위해 UPDATE 또는 DELETE 문을 실행하는 것을 막을 수 없습니다. (T2가 이미 제출했기 때문에 레코드를 변경해도 차단이 발생하지 않습니다.) 이런 방식으로 이 새 레코드의 trx_id 숨겨진 열 값은 be T1의 트랜잭션 ID가 됩니다. 그 후 T1은 일반 SELECT 문을 사용하여 이 레코드를 쿼리할 때 이 레코드를 볼 수 있으며 이 레코드를 클라이언트에 반환할 수 있습니다. MVCC는 이러한 특수 현상으로 인해 가상 읽기를 완전히 제거할 수 없습니다.
MVCC 요약
위의 설명에서 볼 수 있듯이 소위 MVCC(Multi-Version ConcurrencyControl, 다중 버전 동시성 제어)는 READ COMMITTD와 REPEATABLE READ의 두 가지 격리 수준을 사용하여 일반 트랜잭션을 실행하는 것을 의미합니다. SELECT 작업은 기록된 버전 체인에 액세스하는 프로세스입니다. 이를 통해 서로 다른 트랜잭션의 읽기-쓰기 및 쓰기-읽기 작업을 동시에 실행할 수 있으므로 시스템 성능이 향상됩니다.
READ COMMITTD와 REPEATABLE READ의 두 가지 격리 수준의 큰 차이점은 ReadView를 생성하는 타이밍이 다르다는 것입니다. READ COMMITTD는 각 일반 SELECT 작업 전에 ReadView를 생성하는 반면 REPEATABLE READ는 처음으로 ReadView를 생성합니다. SELECT 작업 전에 ReadView를 생성하고 후속 쿼리 작업에 이 ReadView를 재사용하면 기본적으로 팬텀 읽기 현상을 피할 수 있습니다.
기본 키를 업데이트하는 DELETE 문이나 UPDATE 문을 실행하면 페이지에서 해당 레코드가 즉시 완전히 삭제되지 않고 소위 삭제 표시 작업이 수행된다고 앞서 말씀드렸습니다. 레코드의 삭제 플래그는 주로 MVCC용입니다. 또한, 소위 MVCC는 일반적인 SEELCT 쿼리를 수행할 때만 적용됩니다. 지금까지 본 SELECT 문은 모두 일반 쿼리입니다.
위 내용은 MySQL InnoDB의 MVCC 원칙은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!