Innodb 实现高并发、redo/undo MVCC原理

标签：性能   gil   分析   存在   恢复   1.2   特性   nod   undo   

?
因为并发情况下有可能出现不同线程对同一资源进行变动，所以必须要对并发进行控制以保证数据的同一与安全。
?
可以参考CPython解释器中的GIL全局解释器锁，所以说python中没有真正的多线程，多线程任意时刻只有一个程序能申请到GIL操作CPU。

?

锁（lock）
数据多版本（multi versioning）

?

• 使用普通锁来保证数据的一致性:
  ?
  操作数据前实行互斥，即当前程序曹锁数据时，不允许其他并发任务操作该数据，进入排队等待
  操作完成后释放锁
  ?

• 普通锁问题：
  锁定粒度大，容易出现死锁
  简单粗暴，没有并行“读任务”，本质上是串行执行任务。

• 正对上述问题，有了共享锁及排他锁

1. 共享锁（share locks 称为S锁）读取数据时加S锁
   共享锁之间不互斥，简记为：读读可以并行

2. 排他锁（exclusive locks 称为X锁）修改数据时加X锁
   排他锁与任何锁互斥，简记为：写读，写写不可以并行

上述中可以了解到，只要修改数据时加了排他锁， 其它操作同一数据的并行线程都进入了排队等待释放锁。且写的数据没有完成提交的话，其它任务是没法去读取数据的，也阻塞了

?

• 作为一种提高并发的方式：原理

1. 写任务发生时，将数据克隆一份，以版本号区分；

2. 写任务操作新克隆的数据，直至提交；

3. 并发读任务可以继续读取旧版本的数据，不至于阻塞；

• 如上图：

1. 最开始数据的版本是V0；

2. T1时刻发起了一个写任务，这是把数据clone了一份，进行修改，版本变为V1，但任务还未完成；

3. T2时刻并发了一个读任务，依然可以读V0版本的数据；

4. T3时刻又并发了一个读任务，依然不会阻塞；

可以看到，数据多版本，通过“读取旧版本数据”能够极大提高任务的并发度。

总结：

• 普通锁，本质是串行执行

• 读写锁，可以实现读读并发

• 数据多版本，可以实现读写并发

?

• ACID:
  原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）

?

数据库事务提交后，必须将更新后的数据刷到磁盘上，以保证ACID特性。磁盘随机写性能较低，如果每次都刷盘，会极大影响数据库的吞吐量。

优化方式为：将修改行为先写到redo日志里（此时变成了顺序写），再定期将数据刷到磁盘上，这样能极大提高性能。

假如某一时刻，数据库崩溃，还没来得及刷盘的数据，在数据库重启后，会重做redo日志里的内容，以保证已提交事务对数据产生的影响都刷到磁盘上。

一句话，redo日志用于保障，已提交事务的ACID特性。

?

数据库事务未提交时，会将事务修改数据的镜像（即修改前的旧版本）存放到undo日志里，当事务回滚时，或者数据库奔溃时，可以利用undo日志，即旧版本数据，撤销未提交事务对数据库产生的影响。

对于insert操作，undo日志记录新数据的PK(ROW_ID)，回滚时直接删除；

对于delete/update操作，undo日志记录旧数据row，回滚时直接恢复；

他们分别存放在不同的buffer里。

一句话，undo日志用于保障，未提交事务不会对数据库的ACID特性产生影响。

?

存储undo日志的地方，是回滚段。

undo日志和回滚段和InnoDB的MVCC密切相关

?

• MVCC: Multi-Version Concurrency Control
  多版本并发控制：当mysql 开启事务操作时，或者数据库崩溃恢复，都会用到MVCC机制，而不只是单单靠行锁去实现。而是一起使用
  ?
  当使用锁（尤其排他锁-行锁）进行并发控制，开销是非常大的 ，而使用MVCC机制来做，能一定程度的代替行锁，就可以有效降低系统开销

InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的,这两个列，分别保存了这个行的创建时间，一个保存的是行的删除时间。这里存储的并不是实际的时间值,而是系统版本号(可以理解为事务的ID)，没开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID.

如：列子，假设版本好初始为1

create table tb(
id int auto_increment primary key,
name cahr(32));

创建几条数据：insert 操作:第一个事务ID为1

start transaction;
insert into tb(name) values('shenjian') ;
insert into tb(name) values('zhangshan');
insert into tb(name) values('lisi');
commit;

对select 的影响：

1. innodb 只会去查找版本好小于或等于（早于）当前事务ID的数据行，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的

2. 行的删除版本要么未定义,要么大于当前事务版本号,这可以确保事务读取到的行，在事务开始之前未被删除.
   只有1、2同时满足的记录，才能返回作为查询结果.

例2：delete操作
InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)作为删除标识.
看下面的具体例子分析:
第二个事务,ID为2;

start transaction;
select * from tb;  //(第一步操作：1)
select * from tb;  //(第二部操作：2)
commit; 

假设：在这个事务的的执行过程中到第一步操作：1 的时候。
又开启了一个新事务（ID 为3）向表中执行Insert 操作插入数据

start transaction;
insert into tb(name) values('wangwu') ;
commit;

此时的表中数据为：

然后刚才事务2，中的第二步：2 开始执行，引文id=4的数据的创建时间(事务ID为3),执行当前事务的ID为2,而InnoDB只会查找事务ID小于等于当前事务ID的数据行,所以id=4的数据行并不会在执行事务2中的第二步：2 中被检索出来,在事务2中的两条select 语句检索出来的数据都只会下表:

再假设：假设在执行事务ID为2的过程中,刚执行到了第一步：1,假设事务执行完事务3后，接着又执行了事务4;
事务4：

st art transaction;
delete  from tb where id=1;
commit;

此时数据库中的表为：

接着执行事务ID为2的第二步：2,根据select 检索条件可以知道,它会检索创建时间(创建事务的ID)小于当前事务ID的行和删除时间(删除事务的ID)大于当前事务的行,而id=4的行上面已经说过,而id=1的行由于删除时间(删除事务的ID)大于当前事务的ID,所以事务2的第二步：2 select * from tb 会把id=1的数据检索出来.所以,事务2中的两条select 语句检索出来的数据都如下:

update：
InnoDB执行UPDATE，实际上是新插入了一行记录，并保存其创建时间为当前事务的ID，同时保存当前事务ID到要UPDATE的行的删除时间.

再再假设：
假设在执行完事务2的第一步：1 后又执行,其它用户执行了事务3,4,这时，又有一个用户对这张表执行了UPDATE操作:

第5个事务:

start transaction;
update tb set name='xxx' where id=2;
commit;

按照update的更新原则:会生成新的一行,并在原来要修改的列的删除时间列上添加本事务ID,得到表如下:

继续执行事务2第二步：2,根据select 语句的检索条件（创建时间事务ID小于自己查询事务ID的，和删除时间事务ID大于自身的查询事务ID）,得到下表:

并得不到上上个表的ID=4的第四行（因为创建事务ID=3 > 查询事务ID=2） 和第五行Update 事务创建的ID=2 的更新数据（因为 创建他的Update 事务ID=5 > 查询事务ID=2）

Innodb 实现高并发、redo/undo MVCC原理

标签：性能   gil   分析   存在   恢复   1.2   特性   nod   undo   

原文地址：https://www.cnblogs.com/shiqi17/p/9787940.html