mysql版本 mvcc,MySQL MVCC(多版本控制)

1. MySQL 中的事务

MySQL 提供了两种事务型的存储引擎：InnoDB 和 NDB Cluster 。另外还有一些第三方存储引擎也支持事务

1. MySQL 中的事务

1.1. 自动提交(AUTOCOMMIT)

1.2. 在事务中混用存储引擎

2. 多版本并发控制(MVCC)

2.1. InnoDB 的MVCC

3. MySQL 中的事务

3.1. 自动提交(AUTOCOMMIT)

3.2. 在事务中混用存储引擎

4. 多版本并发控制(MVCC)

4.1. InnoDB 的MVCC

1.1. 自动提交(AUTOCOMMIT)

MySQL 默认采用自动提交模式。也就是说每个查询都被当作一个事务执行提交操作，可以设置 AUTOCOMMIT变量来启用或者禁止自动提交模式：

# 查询当前的模式

show variables like'AUTOCOMMIT'

# 禁用自动提交

SET AUTOCOMMIT=0;

当 AUTOCOMMIT=0时，所有的查询都是在一个事务中，直到显示的执行 COMMIT 或者 ROLLBACK AUTOCOMMIT对非事务存储引擎不会有任何影响

1.2. 在事务中混用存储引擎

MySQL 在服务层不管理事务，事务由下层的存储引擎实现，所以在不同的存储引擎中处理同一个事务是不可靠的。 例如： tablea 使用 innodb 引擎， tableb  使用 MyISAM 引擎(不支持事务) 假设以下操作在一个事务中：

insert table_a...# 1

insert table_b...# 2

update table_a...# 3

假设在 执行 # 3 时出现了异常，这时事务要回滚，因为 tableb 并不支持事务，这就导致 tableb 的修改无法回滚，导致违反事务的 一致性 和 原子性

2. 多版本并发控制(MVCC)

MySQL 大部分事务型存储引擎并不是简单的行级锁。基于提升并发行的考虑，它们一般都同时实现了多版本并发控制 MVCC.

2.1. InnoDB 的MVCC

InnoDB 的 MVCC ，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列一把保存了行的创建时间，一个保存行的过期时间(或删除时间)，当然存储的并不是真正的时间，而是系统版本号。每开始一个事务，系统版本号就会自动递增，事务开始时刻的版本号作为当前事务的版本号，用来和查询到的每行记录的版本号就行比较。

以下是 REPEATABLE READ 的隔离级别下具体操作：

SELECT

InnoDB 会根据以下两个条件检查每行记录：

a. InnoDB 只查询版本早于当前事务版本的数据行(也就是，行的系统版本号小于或等于事务的系统版号)，这样可以确保事务读取的行，要么是在事务开始前的已经存在的，要么是事务自身插入或者修改过的。 b. 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

只有符合上述两个条件的记录，才能返回作为查询结果

INSERT

InnoDB 为新插入的每一行保存当前系统版本号作为行版本号

DELETE

InnoDB 为删除的每一行保存当前系统版本号作为行删除标识

UPDATE InnoDB 为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识

保存着两个额外的系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行

=======

3. MySQL 中的事务

MySQL 提供了两种事务型的存储引擎：InnoDB 和 NDB Cluster 。另外还有一些第三方存储引擎也支持事务

3.1. 自动提交(AUTOCOMMIT)

MySQL 默认采用自动提交模式。也就是说每个查询都被当作一个事务执行提交操作，可以设置 AUTOCOMMIT变量来启用或者禁止自动提交模式：

# 查询当前的模式

show variables like'AUTOCOMMIT'

# 禁用自动提交

SET AUTOCOMMIT=0;

当 AUTOCOMMIT=0时，所有的查询都是在一个事务中，直到显示的执行 COMMIT 或者 ROLLBACK AUTOCOMMIT对非事务存储引擎不会有任何影响

3.2. 在事务中混用存储引擎

MySQL 在服务层不管理事务，事务由下层的存储引擎实现，所以在不同的存储引擎中处理同一个事务是不可靠的。 例如： tablea 使用 innodb 引擎， tableb  使用 MyISAM 引擎(不支持事务) 假设以下操作在一个事务中：

insert table_a...# 1

insert table_b...# 2

update table_a...# 3

假设在 执行 # 3 时出现了异常，这时事务要回滚，因为 tableb 并不支持事务，这就导致 tableb 的修改无法回滚，导致违反事务的 一致性 和 原子性

4. 多版本并发控制(MVCC)

MySQL 大部分事务型存储引擎并不是简单的行级锁。基于提升并发行的考虑，它们一般都同时实现了多版本并发控制 MVCC.

4.1. InnoDB 的MVCC

InnoDB 的 MVCC ，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列一把保存了行的创建时间，一个保存行的过期时间(或删除时间)，当然存储的并不是真正的时间，而是系统版本号。每开始一个事务，系统版本号就会自动递增，事务开始时刻的版本号作为当前事务的版本号，用来和查询到的每行记录的版本号就行比较。

以下是 REPEATABLE READ 的隔离级别下具体操作：

SELECT

InnoDB 会根据以下两个条件检查每行记录：

a. InnoDB 只查询版本早于当前事务版本的数据行(也就是，行的系统版本号小于或等于事务的系统版号)，这样可以确保事务读取的行，要么是在事务开始前的已经存在的，要么是事务自身插入或者修改过的。 b. 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

只有符合上述两个条件的记录，才能返回作为查询结果

INSERT

InnoDB 为新插入的每一行保存当前系统版本号作为行版本号

DELETE

InnoDB 为删除的每一行保存当前系统版本号作为行删除标识

UPDATE InnoDB 为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识

保存着两个额外的系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行

喜欢就关注一下哦