mysql事务详解

Posted 2020-12-19 albert32

事务的特性
(Atomicity) 原子性 -- 回滚日志
一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

C(Consistency) 一致性 --
在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
I(Isolation) 隔离性 – 锁
数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
D(Durability) 持久性 – 重做日志
一致性是事务追求的最终目标：前面提到的原子性、持久性和隔离性，都是为了保证数据库状态的一致性；事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

D(Durability) 持久性– 重做日志
作用　　
防止在发生故障的时间点，尚有脏页未写入磁盘（事务提交之后，数据写入磁盘之前宕机），在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

内容
物理格式的日志，记录的是物理数据页面的修改信息，其redo log是顺序写入redo log file的物理文件中去的。重做日志的恢复速度相比逻辑日志要快很多；

产生时间
事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。

释放时间
当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

 

 

 

 

 

更新一条数据的流程：

1、事务发起更新操作
2、从磁盘中读取数据到内存，并更新内存中的数据；
3、生成一条重做日志并写入重做日志缓存；
4、将重做日志缓存中的内容刷新到重做日志文件中
5、将内存中的数据更新到磁盘上

备注：

1、在每次将重做日志缓存写入重做日志文件后，InnoDb存储引擎都需要调用一次fsync操作；

2、数据库的性能->fsync的效率->磁盘的性能；

Innodb存储引擎为了提高数据库的性能，可以手动设置fsync的策略，允许非持久性的情况发生

参数：Innodb_flush_log_at_trx_commit

1：默认值，表示每一次事务提交都需要调用一次fsync操作；
0：事务提交时不进行写入重做日志的操作，仅在master thread中完成，即每1秒完成一次重做日志的文件的fsync操作；
2：表示事务提交时将重做日志缓存写入重做日志文件，单仅写入文件系统的缓存中，不进行fsync操作；数据库发生故障时，只要操作系统不宕机，并不会导致事务的丢失；

 

 

A(Atomicity) 原子性 -- 回滚日志

作用　　

保存了事务发生之前的数据的一个版本，可以用于回滚，可以提供多版本并发控制下的读（MVCC），也即非锁定读

内容　　

逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。

产生时间　　

事务开始之前，生成当前的版本undo log，undo 也会产生 redo 来保证undo log的可靠性

释放时间　　

当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。

 备注：

逻辑日志举例说明：如插入10w条数据后，表空间增大，但是回滚后表空间不会收缩到原来的大小。

 举例说明：

 

 

逻辑日志的另外一种理解，当回滚日志被使用时，它只会按照日志逻辑地将数据库中的修改撤销掉看，使用的每一条 INSERT 都对应了一条 DELETE，每一条 UPDATE 也都对应一条相反的 UPDATE 语句。

 

Purge　　

事务提交后，undo log 不会立即删除，因为可能存在其他的事务需要通过undo log来获取当前版本之前的行记录；即实现MVCC（多版本并发控制）的一致性非锁定读；

一致性非锁定读
如果读取的行正在执行DELETE或UPDATE操作，不需要等待X锁的释放，InnoDB存储引擎会去读取一个快照数据，即该行之前版本的数据，这部分操作是通过undo log来实现的；

当改行记录已经不被任何其他的事务引用时，purge会最终完成undo记录的删除；

Purge根据history list进行undo log的清理，history list是按照事务提交的顺序对undo log进行链接，这样设计是为了避免线程进行大量的随机读取操作，提高purge的效率

 

I(Isolation) 隔离性 –事务的隔离级别

RAED UNCOMMITED
事务读取到其他事务未提交的数据，是级别最低的隔离机制；

READ COMMITED
事务读取到其他事务提交后的数据；

REPEATABLE READ
事务对同一份数据读取到的相同，不在乎其他事务对数据的修改；
InnoDB默认的隔离级别，通过Next-Key Lock避免幻读；

SERIALIZABLE
事务串行化执行，隔离级别最高，牺牲了系统的并发性；

 

 

脏读：

事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据；
不可重复读：

事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致；
幻读：

同一事务中对同一范围的数据进行读取，结果却多出了数据或者少了数据，这就叫幻读。

不可重复读和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。
解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表