MySQL은 InnoDB의 MVCC 원칙을 요약합니다.

이 기사에서는 InnoDB의 MVCC 원칙과 관련된 문제를 주로 소개하는 mysql에 대한 관련 지식을 제공합니다. MVCC는 주로 데이터베이스의 동시성 성능을 향상시키기 위한 다중 버전 동시성 제어입니다. 그것이 모두에게 도움이 되기를 바랍니다.

추천 학습: mysql 비디오 튜토리얼

MVCC는 Multi-Version Concurrency Control의 약자로, 주로 데이터베이스의 동시성 성능을 향상시키기 위한 다중 버전 동시성 제어입니다. 동일한 데이터 행에 대해 읽기 또는 쓰기 요청이 발생하면 해당 행이 잠겨 차단됩니다. 그러나 MVCC는 읽기-쓰기 요청을 처리하는 더 나은 방법을 사용하므로 읽기-쓰기 요청 충돌이 발생할 때 잠금이 발생하지 않습니다. 이 읽기는 현재 읽기가 아닌 스냅샷 읽기를 참조합니다. 현재 읽기는 잠금 작업이며 비관적 잠금입니다. 그렇다면 잠그지 않고 어떻게 읽고 쓸 수 있습니까? 스냅샷 읽기와 현재 읽기는 무엇을 의미합니까? 우리 모두는 나중에 이것을 배울 것입니다.

MySQL은 REPEATABLE READ 격리 수준에서 팬텀 읽기 문제를 대부분 방지할 수 있습니다. MySQL은 이를 어떻게 수행합니까?

버전 체인

우리는 InnoDB 스토리지 엔진을 사용하는 테이블의 경우 클러스터형 인덱스 레코드에 두 개의 필수 숨겨진 열이 포함되어 있음을 알고 있습니다(row_id는 필요하지 않으며, 우리가 만든 테이블에는 기본 키가 있거나 NULL이 아닌 UNIQUE 키가 있음) row_id 열은 포함하지 않음):

• trx_id: 트랜잭션이 클러스터형 인덱스 레코드를 변경할 때마다 트랜잭션의 트랜잭션 ID가 trx_id 숨겨진 열에 할당됩니다.

• roll_pointer: 클러스터형 인덱스 레코드가 수정될 때마다 이전 버전이 실행 취소 로그에 기록됩니다. 그러면 이 숨겨진 열은 수정 전 레코드를 찾는 데 사용할 수 있는 포인터와 같습니다.

이 문제를 설명하기 위해 데모 테이블을 만듭니다.

CREATE TABLE `teacher` (
  `number` int(11) NOT NULL,
  `name` varchar(100) DEFAULT NULL,
  `domain` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`number`)) ENGINE=InnoDB DEFAULT CHARSET=utf8

그런 다음 이 테이블에 데이터 조각을 삽입합니다.

mysql> insert into teacher values(1, 'J', 'Java');Query OK, 1 row affected (0.01 sec)

이제 데이터는 다음과 같습니다.

mysql> select * from teacher;
+--------+------+--------+
| number | name | domain |
+--------+------+--------+
|      1 | J    | Java   |
+--------+------+--------+
1 row in set (0.00 sec)

레코드 삽입의 트랜잭션 ID가 다음과 같다고 가정합니다. 60이면 현재 레코드의 도식은 다음과 같습니다.

트랜잭션 ID가 80과 120인 두 트랜잭션이 이 레코드에 대해 UPDATE 작업을 수행한다고 가정합니다.

선생님 업데이트 set name='T ' 여기서 숫자=1;update 교사 세트 이름 = 'K' 여기서 숫자=1; =' F' ;커밋

每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：

对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id。于是可以利用这个记录的版本链来控制并发事务访问相同记录的行为，那么这种机制就被称之为多版本并发控制(Mulit-Version Concurrency Control MVCC)。

ReadView

对于使用READ UNCOMMITTED隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了。

对于使用SERIALIZABLE隔离级别的事务来说，InnoDB使用加锁的方式来访问记录。

对于使用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是：READ COMMITTED和REPEATABLE READ隔离级别在不可重复读和幻读上的区别，这两种隔离级别关键是需要判断一下版本链中的哪个版本是当前事务可见的。

为此，InnoDB提出了一个ReadView的概念，这个ReadView中主要包含4个比较重要的内容：

• m_ids：表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。

• min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值。

• max_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。注意max_trx_id并不是m_ids中的最大值，事务id是递增分配的。比方说现在有id为1，2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4。

• creator_trx_id：表示生成该ReadView的事务的事务id。

有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：

1. 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
2. 如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
3. 如果被访问版本的trx_id属性值大于或等于ReadView中的max_trx_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
4. 如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间(min_trx_id
5. 如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。

在MySQL中，READ COMMITTED和REPEATABLE READ隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同。

我们还是以表teacher为例，假设现在表teacher中只有一条由事务id为60的事务插入的一条记录，接下来看一下READ COMMITTED和REPEATABLE READ所谓的生成ReadView的时机不同到底不同在哪里。

READ COMMITTED每次读取数据前都生成一个ReadView

假设现在系统里有两个事务id分别为80、120的事务在执行：

# 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'

这个SELECE1的执行过程如下：

• 在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[80, 120]，min_trx_id为80，max_trx_id为121，creator_trx_id为0。

• 然后从版本链中挑选可见的记录，最新版本的列name的内容是’T’，该版本的trx_id值为80，在m_ids列表内，根据步骤4不符合可见性要求，根据roll_pointer跳到下一个版本。

• 下一个版本的列name的内容是’S’，该版本的trx_id值也为80，也在m_ids列表内，根据步骤4也不符合要求，继续跳到下一个版本。

• 下一个版本的列name的内容是’J’，该版本的trx_id值为60，小于ReadView 中的min_trx_id值，根据步骤2判断这个版本是符合要求的。

之后，我们把事务id为80的事务提交一下，然后再到事务id为120的事务中更新一下表teacher 中number为1的记录：

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;

此刻，表teacher 中number为1的记录的版本链就长这样：

然后再到刚才使用READ COMMITTED隔离级别的事务中继续查找这个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'

这个SELECE2 的执行过程如下：

• 在执行SELECT语句时会又会单独生成一个ReadView，该ReadView的m_ids列表的内容就是[120]（事务id为80的那个事务已经提交了，所以再次生成快照时就没有它了），min_trx_id为120，max_trx_id为121，creator_trx_id为0。
• 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是’F’，该版本的trx_id值为120，在m_ids列表内，根据步骤4不符合可见性要求，根据roll_pointer跳到下一个版本。
• 下一个版本的列name 的内容是’K’，该版本的trx_id值为120，也在m_ids列表内，根据步骤4不符合可见性要求，根据roll_pointer跳到下一个版本。
• 下一个版本的列name的内容是’T’，该版本的trx_id值为80，小于ReadView中的min_trx_id值120，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为’‘T’'的记录。

以此类推，如果之后事务id为120的记录也提交了，再次在使用READCOMMITTED隔离级别的事务中查询表teacher中number值为1的记录时，得到的结果就是’F’了，具体流程我们就不分析了。

总结一下就是：使用READCOMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView。

REPEATABLE READ —— 在第一次读取数据时生成一个ReadView

对于使用REPEATABLE READ隔离级别的事务来说，只会在第一次执行查询语句时生成一个ReadView，之后的查询就不会重复生成了。我们还是用例子看一下是什么效果。

假设现在系统里有两个事务id分别为80、120的事务在执行：

# Transaction 80
begin
update teacher set name='S' where number=1;
update teacher set name='T' where number=1;

此刻，表teacher中number为1的记录得到的版本链表如下所示：

假设现在有一个使用REPEATABLE READ隔离级别的事务开始执行：

# 使用REPEATABLE READ隔离级别的事务
begin;
# SELECE1：Transaction 80、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'

这个SELECE1的执行过程如下（与READ COMMITTED的过程一致）：

• 在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[80, 120]，min_trx_id为80，max_trx_id为121，creator_trx_id为0。

• 然后从版本链中挑选可见的记录，最新版本的列name的内容是’T’，该版本的trx_id值为80，在m_ids列表内，根据步骤4不符合可见性要求，根据roll_pointer跳到下一个版本。

• 下一个版本的列name的内容是’S’，该版本的trx_id值也为80，也在m_ids列表内，根据步骤4也不符合要求，继续跳到下一个版本。

• 下一个版本的列name的内容是’J’，该版本的trx_id值为60，小于ReadView 中的min_trx_id值，根据步骤2判断这个版本是符合要求的。

之后，我们把事务id为80的事务提交一下，然后再到事务id为120的事务中更新一下表teacher 中number为1的记录：

# Transaction 80
begin
update teacher set name='K' where number=1;
update teacher set name='F' where number=1;

此刻，表teacher 中number为1的记录的版本链就长这样：

然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个number为1的记录，如下：

# 使用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'

这个SELECE2的执行过程如下：

• 현재 트랜잭션의 격리 수준이 REPEATABLE READ이고, SELECE1을 실행할 때 이전에 ReadView가 생성되었으므로 이때 이전 ReadView를 직접 재사용하기 때문입니다. 이전 ReadView의 m_ids 목록 내용은 [80, 120입니다. ], min_trx_id는 80, max_trx_id는 121, creator_trx_id는 0입니다.
• 그런 다음 버전 체인에서 보이는 레코드를 선택합니다. 그림에서 볼 수 있듯이 최신 버전의 열 이름 내용은 'F'입니다. 이 버전의 trx_id 값은 120입니다. 4단계에 따라 표시되지 않습니다. 성적 요구사항, Roll_pointer에 따라 다음 버전으로 이동합니다.
• 다음 버전의 열 이름 내용은 'K'입니다. 이 버전의 trx_id 값은 120이며, 이는 4단계에 따르면 가시성 요구 사항을 충족하지 않아 다음 버전으로 이동합니다. Roll_pointer에 따른 다음 버전.
• 다음 버전의 열 이름 내용은 'T'입니다. 이 버전의 trx_id 값은 80이며, 이는 4단계에 따르면 가시성 요구 사항을 충족하지 않아 다음 버전으로 이동합니다. Roll_pointer에 따른 다음 버전.
• 다음 버전의 열 이름 내용은 'S'입니다. 이번 버전의 trx_id 값은 80인데, 이는 4단계에 따르면 가시성 요구 사항을 충족하지 않아 다음 버전으로 이동합니다. Roll_pointer에 따른 다음 버전.
• 다음 버전의 열 이름 내용은 'J'입니다. 이 버전의 trx_id 값은 ReadView의 min_trx_id 값 80보다 작으며, 이는 이 버전을 생성한 트랜잭션이 이전에 커밋되었음을 나타냅니다. 현재 트랜잭션은 ReadView를 생성하므로 이 버전은 요구 사항이 충족되면 사용자에게 반환되는 최종 버전은 열 이름이 ''J''인 레코드입니다.

즉, 두 개의 SELECT 쿼리로 얻은 결과가 반복되어 기록된 열 값이 모두 ''J''''라는 의미입니다.

나중에 트랜잭션 ID가 120인 레코드를 제출한 후 방금 REPEATABLE READ 격리 수준을 사용한 트랜잭션에서 1번 레코드를 계속 검색하면 결과는 여전히 'J'인 것을 확인할 수 있습니다. 실행과정을 직접 분석해보세요.

MVCC에서의 팬텀 리딩 현상과 팬텀 리딩 솔루션

우리는 MVCC가 REPEATABLE READ 격리 수준에서 반복 불가능한 읽기 문제를 해결할 수 있다는 것을 이미 알고 있지만, 팬텀 리딩은 어떻습니까? MVCC는 어떻게 해결되나요? 팬텀 읽기(Phantom reading)는 트랜잭션이 동일한 조건에 따라 레코드를 여러 번 읽는 것이며, 마지막 읽기는 이전에 읽지 않은 레코드를 읽는 것이며, 이 레코드는 다른 트랜잭션에 의해 추가된 새로운 레코드에서 나온 것입니다.

생각해보면 REPEATABLE READ 격리 수준의 트랜잭션 T1은 먼저 특정 검색 조건을 기반으로 여러 레코드를 읽은 다음 트랜잭션 T2가 해당 검색 조건을 충족하는 레코드를 삽입하여 제출하고 그런 다음 트랜잭션 T1이 기반으로 다시 검색합니다. 동일한 쿼리 조건부 실행에서. 결과는 어떻게 될까요? ReadView의 비교 규칙에 따르면:

트랜잭션 T2가 트랜잭션 T1 이전에 열렸는지 여부에 관계없이 트랜잭션 T1은 T2의 제출을 ​​볼 수 없습니다. 위에서 소개한 버전 체인, ReadView 및 가시성 판단 규칙에 따라 직접 분석해 보세요.

그러나 REPEATABLE READ 격리 수준에서 InnoDB의 MVCC는 팬텀 읽기를 완전히 금지하는 것이 아니라 팬텀 읽기를 상당 부분 방지할 수 있습니다. 무슨 일이야? 다음 상황을 살펴보겠습니다.

Trx80	업데이트 교사 세트 이름='S', 여기서 번호= 1;
commit

T1	T2
begin;
select * from Teacher where number=30; No data	begin;
	교사 값에 삽입(30, 'X', 'Java');
	commit;
update Teacher set domain='MQ' 여기서 숫자=30;	select * from 숫자 = 30인 교사
	뭐야, 무슨 일이야? 트랜잭션 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 비디오 튜토리얼

위 내용은 MySQL은 InnoDB의 MVCC 원칙을 요약합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!