MySql(四) InnoDB事务浅析

在写上一篇 MySql 锁机制的时候就一直在想关于InnoDb事务的问题，一直拖到了现在才写这篇博客。一方面是时间问题，另一方面是事务系统实在是太复杂了，查阅了很多资料梳理了很久，有很多零碎生涩的概念。文中有些地方只是粗略的带过，讲得不清楚或者是错误的希望大家包容并指出:joy:

事务的四个条件

事务满足的4个条件（ACID）：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）

1. 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态。
2. 一致性：指的是在任何时刻，包括数据库正常提供服务的时候，数据库从异常中恢复过来的时候，数据都是一致的，保证不会读到中间状态的数据。
3. 隔离性：允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
4. 持久性：指的是事务commit的数据在任何情况下都不能丢。

实现： InnoDB通过undolog保证rollback的时候能找到之前的数据保证了原子性；通过crash recovery和double write buffer的机制保证数据的一致性。通过redolog保证持久性。隔离性则由锁和mvcc保证。

重要结构体的概念

undo segments

InnoDB 提供了多种方式来开启一个事务，所有显式开启事务的行为都会隐式的将上一条事务提交掉。

• BEGIN、BEGIN WORK、START TRANSACTION：执行BEGIN命令并不会真的去引擎层(InnoDB)开启一个事务，仅仅是为当前线程设定标记，表示为显式开启的事务。
• START TRANSACTION READ ONLY：为当前线程的thd->tx_read_only设置为true。当Server层接受到任何数据更改的 SQL 时，都会直接拒绝请求，返回错误不会进入引擎层。
• START TRANSACTION READ WRITE：允许super用户在read_only参数为true的情况下启动读写事务。
• START TRANSACTION WITH CONSISTENT SNAPSHOT：这种启动方式会进入引擎层层，并开启一个readview。只有在RR隔离级别下，这种操作才有效，否则会报错。

除了with consistent snapshot的方式会进入InnoDB层，其他所有的方式都只是在Server层做个标记，没有进入InnoDB做标记，在InnoDB看来所有的事务在启动时候都是只读状态，只有接受到修改数据的SQL后才把只读事务提升为读写事务。 读写事务需要分配事务id，分配回滚段，加入到全 局读写事务链表( rw_trx_list )，把事务id加入到活跃读写事务数组中( descriptors ) 。

实例分析1(RR级别)

在book表中有一条记录id:1,name:book1;按顺序执行下列语句
事务1：BEGIN;(1)
SELECT * FROM book_book WHERE id = 1;(5)
COMMIT;(6)
事务2：BEGIN;(2)
UPDATE book_book SET name = 'book2' WHERE id = 1;(3)
COMMIT;(4)复制代码

分析：结果(5)查出来的name为book2，明明事务1比事务2先，为什么事务1读到了2中提交的内容？ 这实际上涉及到了readview一致性读的问题，在RR级别下事务1开始时并不会去给事务系统trx_sys打快照生成readview，而是在第一条SQL语句执行时生成的readview。这时事务2已经提交，事务2id在r eadview中 up-low之间且 descriptors中不存在事务2id，所以事务1能读到事务2修改的数据。如果事务1是 用with consistent snapshot方式开启事务那么便不能读到事务2修改的数据，因为此时readview中的low_limit_id等于事务2id。此外在RC级别下每次执行SQL都会生成readview。

这里讲到了一致性读(又称快照读)即普通select，对于加锁的select和delete、update、insert成为当前读。

Undo log

undo log作用：提供回滚和MVCC。在数据修改的时候，记录了相对应的undo，如果事务失败或回滚了，可以借助该undo进行回滚。 undo log是逻辑日志，记录更改前的镜像。当需要当前读的时候，它可以从undo log中分析出该行记录以前的数据提供版本信息。 另外undo log也会产生redo log，因为undo log也要实现持久性保护。

事务提交

1.  使用全局事务id产生器生成事务no，然后把事务trx_t加入到trx_serial_list。
2. 标记undo，如果这个事务只使用了一个undopage且使用量小于四分之三个page，则把这个page标记为(TRX_UNDO_CACHED)。如果不满足且是insert undo则标记为TRX_UNDO_TO_FREE，否则undo为update undo则标记为TRX_UNDO_TO_PURGE。标记为TRX_UNDO_CACHED的undo会被回收，方便下次重新利用。 
3. 把update undo放入所在undo segment的history list，并递增rseg_history_len(全局)。同时更新page上的TRX_UNDO_TRX_NO, 如果删除了数据，则重置delete_mark。
4.  把undate undo从update_undo_list中删除，如果被标记为TRX_UNDO_CACHED，则加入到update_undo_cached队列中。
5.  mtr_commit(日志undo/redo写入公共缓冲区)，至此，在文件层次事务提交。这个时候即使crash，重启后依然能保证事务是被提交的。接下来要做的是内存数据状态的更新(trx_commit_in_memory)。 
6. 只读事务只需要把readview从全局readview链表中移除，然后重置trx_t结构体里面的信息即可。读写事务首先需要是设置事务状态为TRX_STATE_COMMITTED_IN_MEMORY，其次，释放所有行锁，接着，trx_t从rw_trx_list中移除，readview从全局readview链表中移除，另外如果有insert undo则在这里移除(update undo在事务提交前就被移除，主要是为了保证添加到history list的顺序)，如果有update undo，则唤醒Purge线程进行垃圾清理，最后重置trx_t里的信息，便于下一个事务使用。

在book表中有一条记录id:1,name:book1;按顺序执行下列语句
事务一：BEGIN;(1)
SELECT * FROM book_book WHERE id = 1;(3)
SELECT * FROM book_book WHERE id = 1;(6)
UPDATE book_book SET `name` = 'book3' WHERE id = 1 AND `name` = 'book2';(7)
SELECT * FROM book_book WHERE id = 1;(8)
COMMIT;(9)
事务二：BEGIN;(2)
UPDATE book_book SET `name` = 'book2' WHERE id = 1;(4)
COMMIT;(5)复制代码

(1)BEGIN;
(2)UPDATE book_book SET `name` = 'book2' WHERE id = 1; undolog、redolog
(3)INSERT INTO `book_book` (`id`, `name`) VALUES ('2', 'JAVA面向对象编程'); undolog、redolog
(COMMIT)
(4)undo log buffer中undolog写入磁盘
(5)redo log buffer中redolog写入磁盘
(6)dbbuffer中数据写入磁盘复制代码

关于redolog(物理日志记录数据页的变化，保证事务的持久性用来在crash后恢复事务)和binlog(逻辑日志记录数据或者sql)等日志有兴趣的同学可以深入了解

MySQL系列其他文章：

MySql(一) 浅析MySql索引

MySQL(二) MySql常用优化

MySql(三) MySql中的锁机制

参考文章：https://dev.mysql.com/doc/refman/5.7/en/innodb-undo-logs.html
https://www.aliyun.com/jiaocheng/1107450.html?spm=5176.100033.2.5.31613561FIMCB3
http://mysql.taobao.org/monthly/2017/12/01/?spm=a2c4e.11153940.blogcont560506.19.4b32720fTYF6D3
复制代码