一致性读实现原理是什么

本篇内容主要讲解“一致性读实现原理是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“一致性读实现原理是什么”吧!

创新互联是网站建设专家,致力于互联网品牌建设与网络营销，专业领域包括成都网站设计、做网站、电商网站制作开发、微信小程序开发、微信营销、系统平台开发，与其他网站设计及系统开发公司不同，我们的整合解决方案结合了恒基网络品牌建设经验和互联网整合营销的理念，并将策略和执行紧密结合，且不断评估并优化我们的方案，为客户提供全方位的互联网品牌整合方案！

MySQL中的事务

事务在RDBMS系统中概念基本都是一样的，是由一组DML语句构的工作单元，要么全部成功，要么全部失败。

开发过程中，比较关心长事务，即包含DML语句多的工作单元，事务太长会导致一些错误，例如可能由于事务数据包大小超过参数max_allowed_packet设置会导致程序报错，也可能有事务中某个SQL对应接口报错，导致整个服务调用失败，在程序设计时，应该考虑避免长事务带来的业务影响。

事务的ACID

image-20201114221841801

原子性是事务隔离的基础，隔离性和持久性是手段，最终目的是为了保持数据的一致性。

事务的并发问题

• 脏读：事务A读取了事务B未提交的数据。

• 不可重复度：事务A多次读取同一份数据，事务B在此过程中对数据修改并提交，导致事务A多次读取同一份数据的结果不一致。

• 幻读：事务A修改数据的同时，事务B插入了一条数据，当事务A提交后发现还有数据没被修改，产生了幻觉。

不可重复读侧重于update操作，幻读侧重于insert或delete。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。

事务隔离级别

事务隔离是数据库处理的基础之一，隔离级别在多个事务同时进行更改和执行查询时，对性能与结果的可靠性、一致性和可再现性之间的平衡进行调整，InnoDB利用不同的锁策略支持不同隔离级别。MySQL中有四种隔离级别，分别是读未提交(READ  UNCOMMITTED)，读已提交(READ COMMITTED)，可重复读(REPEATABLE READ)以及串行化(SERIALIZABLE)。

InnoDB并发控制

MVCC特性

InnonDB是一个支持行锁的存储引擎，为了提供更好支持的并发，使用了非锁定读，不需要等待访问数据上的锁释放，而是读取行的一个快照，该方法是通过InnonDB  MVCC特性实现的。

MVCC是Multi-Version Concurrency  Control的简称，即多版本并发控制，作用是让事务在并行发生时，在一定隔离级别前提下，可以保证在某个事务中能实现一致性读，也就是该事务启动时根据某个条件读取到的数据，直到事务结束时，再次执行相同条件，还是读到同一份数据，不会发生变化。

MVCC的好处

读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，可以增加系统的并发性能。

在MVCC中，有两种读操作：快照度和当前读。

MVCC快照

MVCC内部使用的一致性读快照称为Read  View，在不同的隔离级别下，事务启动时或者SQL语句开始时，看到的数据快照版本可能也不同，在RR、RC隔离级别下会用到 Read view。

InnoDB 里面每个事务有一个唯一的事务ID，称为Transaction  ID，它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。而每行数据都有多个版本。每次事务更新数据的时候，都会生成一个新的数据版本Read  View，并且把Transaction ID赋值给这个数据版本的事务 ID，标记为  row_trx_id。同时旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它,数据表中的一行记录，其实可能有多个数据版本 ，每个版本有自己的  row_trx_id。

InnoDB行格式

目前InnoDB默认的行格式Dynamic，是Compat格式的增强版，记录头结构信息占用5个字节，事务ID和回滚指针分别占用6和7个字节，行格式如下：

记录头结构

数据行存储

#创建表 mysql> create table store_users (id int not null auto_increment primary key comment '主键id',name varchar(20) not null default '' comment '姓名'); # 查看表状态信息 mysql> show table status like 'store_users'\G      Row_format: Dynamic    #默认行格式为Dynamic            Rows: 0          #行数  Avg_row_length: 0          #平均行长度     Data_length: 16384      #初始化段大小16K      #开启事务，插入数据 mysql> begin; mysql> insert into store_users values(null, 'aaaaa'),(null, 'bbbbb'); #查看InnoDB分配的事务ID mysql> select trx_id from information_schema.innodb_trx\G trx_id: 8407246  #事务ID

分析表的行头信息以及隐藏的事务ID和回滚指针。

# 用Linux下的工具hexdump进行分析 $ hexdump -C -v /usr/local/var/mysql/test/store_users.ibd > store_users.txt  $ vi store_users.txt 00010060  02 00 1b 69 6e 66 69 6d  75 6d 00 03 00 0b 00 00  |...infimum......| 00010070  73 75 70 72 65 6d 75 6d  05 00 00 10 00 1c 80 00  |supremum........| 00010080  00 01 00 00 00 80 48 ce  83 00 00 01 d8 01 10 61  |......H........a|   #Record Header信息 00010090  61 61 61 61 05 00 00 18  ff d6 80 00 00 02 00 00  |aaaa............| 000100a0  00 80 48 ce 83 00 00 01  d8 01 1d 62 62 62 62 62  |..H........bbbbb| 000100b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

• 10表示变长字段长度，只有一个varchar(20)没有超过256字节，且没有NULL值。

• 00代表NULL标志位，第一行没有为NULL数据。

• 字符a的十六进制是61，即61 61 61 61 61代表的是字段值aaaaa

• 00 00 00 80 48 ce 6个字节就是Transaction  ID，转换成十进制8407246，正是上面information_schema.innodb_trx.trx_id列的值，trx_id: 8407246  。

• 83 00 00 01 d8 01 10 7个字节是Rollback Pointer。

• 1c 80 00 00 01 是5个字节，代表Record Header信息。

隔离级别与快照

REPEATABLE READ

默认的隔离级别，一致读快照(Read View)是在第一次SELECT发起时建立，之后不会再发生变化。如果在同一个事务中发出多个非  锁定SELECT语句，那么这些SELECT语句在事务提交前返回的结果是一致的。

在RR下快照Read View不是事务发起时创建，而是在第一个SELECT发起后创建。

READ COMMITTED

在READ COMMITTED读已提交下，一致读快照(Read View)是在每次SELECT后都会生成最新的Read  View，即每次SELECT都能读取到已COMMIT的数据，就会存在不可重复读、幻读 现象。

Undo回滚段

当开启事务执行更新语句(insert/update/deeldte)，会经过Server层的处理生成执行计划，然后调用存储引擎层接口去读写数据，用户没有触发COMMIT或ROLLBACK之前，这些Uncommitted  Data的数据称为前镜像(Post Image)，数据存储在Undo Log，以便用户回滚或者MySQL Server Crash的恢复，同时Undo  Log是循环覆盖使用。

#开启事务，更新账户余额，不提交事务。 mysql> start transaction; mysql> update account set balance = 100000 where account_no = 10001; Rows matched: 1  Changed: 1  Warnings: 0

上面在RR隔离级别下，开启一个事务，做update更新操作，不提交事务，通过show engine innodb  status\G查看undo情况。

Trx id counter 8407258 Purge done for trx's n:o < 8407257 undo n:o < 0 state: running but idle History list length 33 ...... ---TRANSACTION 8407257, ACTIVE 154 sec 2 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 1

Trx id counter 8407258当前的事务ID，undo log entries 1使用了的undo entries，ACTIVE 154  sec事务持续时间，事务commit后，会调用Purge Thread把undo中的老数据清理掉。

回滚记录

insert：反向操作是delete，undo里记录的是delete相关信息，存储主键id即可。

udpate：反向操作是update，undo里记录的是update前的相关数据。

delete：反向操作是insert，undo里记录的是insert values(…..)相关的记录。

从这里可以知道，更新操作占用Undo空间的大小排序如下：

delete > update > insert

所以不建议物理delete删除数据，会产生大量的Undo  Log，Undo快被写满就会发生切换，在次期间会有大量的IO操作，导致业务的DML都会变得很慢。

一致性读

MySQL官方文档对一致读的描述：

读操作基于某个时间点得到一份那时的数据快照，而不管同时其他事务对数据的修改。查询过程中，若其他事务修改了数据，那么就需要从 undo  log中获取旧版本的数据。这么做可以有效避免因为需要加锁(来阻止其他事务同时对这些数据的修改)而导致事务并行度下降的问题。

在可重复读(REPEATABLE READ，简称RR)隔离级别下，数据快照版本是在第一个读请求发起时创建的。在读已提交(READ  COMMITTED，简称RC)隔离级别下，则是在每次读请求时都会重新创建一份快照。

一致性读是InnoDB在RR和RC下处理SELECT请求的默认模式。由于一致性读不会在它请求的表上加锁，其他事务可以同时修改数据不受影响。

一行数据有多个版本，每个数据版本有自己的trx_id，每个事务或者查询通过trx_id生成自己的一致性视图。普通select语句是一致性读，一致性读会根据row  trx_id和一致性视图确定数据版本的可见性，图中UR1，UR2就是undo，存储在Undo Log中，每次查询时根据当前data page和 Undo  page构造出一致性数据页(Consistent Read Page)，通过读取CR Page将数据返回给用户。

到此，相信大家对“一致性读实现原理是什么”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！