mysql innodb事务的ACID及其实现的保证机制

MySQL事务的ACID，一致性是最终目的。
保证一致性的措施有：
A原子性：靠undo log来保证（异常或执行失败后进行回滚）。
D持久性：靠redo log来保证（保证当MySQL宕机或停电后，可以通过redo log最终将数据保存至磁盘中）。
I隔离性：事务间的读写靠MySQL的锁机制来保证隔离，事务间的写操作靠MVCC机制（快照读、当前读）来保证隔离性。
C一致性：事务的最终目的，即需要数据库层面保证，又需要应用层面进行保证，并且MySQL底层通过两阶段提交事务保证了事务持久化时的一致性。

注：什么是undo log和redo log
undo log 属于逻辑日志，它记录的是SQL执行相关的信息。当事务对数据库进行修改时，InnoDB会生成与之对应的undo log。如果事务执行失败或者调用的rollback，导致事务需要回滚，InnoDB引擎会根据undo log中的记录，将数据回滚到之前的样子。

redo log：持久性是指事务一旦提交，对数据库的操作就是永久性的，接下来的其他操作和异常故障不应该对它有任何影响。
我们都知道MySQL的数据最终是存放在磁盘中的，所以才会有磁盘的容量大小决定数据容量的大小。但是如果对MySQL的操作都是通过读写磁盘来进行的话，那么光是磁盘的I/O就够把效率大大的拉低了。
所以InnoDB为MySQL提供了缓冲池（Buffer Pool）,Buffer Pool中包含了磁盘中部分数据页的映射。
当从数据库读取数据时，会先从Buffer Pool中读取数据，如果Buffer Pool中没有，则从磁盘读取后放入到Buffer Pool中。
当向数据库写入数据时，会先写入到Buffer Pool中，Buffer Pool中更新的数据会定期刷新到磁盘中（此过程称为刷脏）。
虽然Buffer Pool为MySQL的读写提高了效率，但是却也带来了新的问题，那就是如果数据刚更新到Buffer Pool中还没来得及刷新到磁盘中时，MySQL突然宕机了，这就会导致数据丢失，造成事务的持久性无法保证了。
为了解决这个缓存的一致性问题，redo log就出现了。在对Buffer Pool中的数据进行修改的时候通过redo log记录这次操作，当事务提交时会通过fsync接口对redo log进行刷盘。
因为在事务提交时会把redo log是同步在磁盘中的，所以当MySQL出现宕机时，可以从磁盘中读取redo log进行数据的恢复，从而保证了事务的持久性。
redo log 采用的预写的方式记录日志，即先记录日志，再更新Buffer Pool，这样就强行的保证了，数据只要保存在了redo log中就一定会存储到磁盘中了。

这要解释一下，redo log 也是写磁盘，刷脏也是写磁盘，为啥要先记录redo log而不是直接刷脏？
主要原因就是redo log比刷脏快很多。
第一点是，redo log是追加操作日志，是顺序IO；而刷脏是随机IO，因为每次更新的数据不一定是挨着的，也就是随机的。
第二点是，刷脏是以数据页（Page）为单位的（即每次最少从磁盘中读取一页数据到内存，或者最少刷一页数据到磁盘），MySQL默认页大小是16KB，对一个页上的修改，都要整个页都刷到磁盘中；而redo log只包含真正的需要写入磁盘的操作日志。
————————————————
版权声明：本文为CSDN博主「YangYoung_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/YangYoung_/article/details/117195841

atomicity原子性
一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。

如何保证：

通过redo log来保证，回放redo log

Consistency一致性
数据如果有约束性，那么事务执行前后，数据的约束性还是存在的，并没有破坏掉。比如说转账事务的前后，资金的总数这个约束条件是不会被破坏的

如何保证：

通过undo log，回滚机制来保证

Isolation隔离性
这个是很不好理解的一个含义。我觉得姜承尧老师讲的比较好。

多个事务并行，一个事务所做的更改，不管有没有提交，在并行的另一个事务中都是不可见的，但最后的效果看起来多个并行的事务好像是串行一样

如何保证：

通过lock来保证

* locking （锁）
* concurrency control （并发控制）
* isolation （隔离级别）
* serializability （序列化）

以上四个其实在数据库中讲的是同一个概念； 锁是用来实现并发控制，并发控制用来实现隔离级别，隔离级别是通过锁来控制的，锁的目的为了使得事务之间的执行是序列化的

Duration持久性
一旦事务提交，其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。这个duration指的是mysql服务器可以重启的情况下，crash掉之后（比如说只写到pool buffer中，还没有fsync到磁盘文件中），保证duration。而不是物理损坏，物理损坏由备份来负责的

如何保证：

是通过redo log来保证的。

事务的ACID如何保证

一些概念名词

redo log: 重做日志
ib_logfile0~1 默认50M , 轮询使用

redo log buffer :
redo内存区域

ibd :
存储 数据行和索引

data buffer pool :
缓冲区池,数据和索引的缓冲

LSN : 日志***
ibd ,redolog ,data buffer pool, redo buffer
MySQL 每次数据库启动,都会比较磁盘数据页和redolog的LSN,必须要求两者LSN一致数据库才能正常启动

WAL (持久化):
write ahead log 日志优先写的方式实现持久化
日志是优先于数据写入磁盘的.

脏页:
内存脏页,内存中发生了修改,没写入到磁盘之前,我们把内存页称之为脏页.

CKPT:
Checkpoint,检查点,就是将脏页刷写到磁盘的动作

TXID:
事务号,InnoDB会为每一个事务生成一个事务号,伴随着整个事务.

事务日志-- redo 重做日志
主要功能 保证 “D” , A C 也有一定得作用
(1)记录了内存数据页的变化.
(2)提供快速的持久化功能(WAL)
(3)CSR过程中实现前滚的操作(磁盘数据页和redo日志LSN一致)

redo日志位置
redo的日志文件：iblogfile0 iblogfile1

redo buffer
redo的buffer:数据页的变化信息+数据页当时的LSN号

redo的刷写策略
commit;
刷新当前事务的redo buffer到磁盘
还会顺便将一部分redo buffer中没有提交的事务日志也刷新到磁盘
MySQL : 在启动时,必须保证redo日志文件和数据文件LSN必须一致, 如果不一致就会触发CSR,最终保证一致

redo
(1) 记录 内存数据页变化日志
(2) 提供 快速的事务的提交(commit)
(3) CSR redo提供的前滚的功能

undo
(1) 记录 数据修改之前的状态
(2) 提供 事务工作过过程中回滚操作(rollback)
(3) CSR 中将未提交的事务进行回滚

情况一:
我们做了一个事务,begin;update;commit.
1.在begin ,会立即分配一个TXID=tx_01.
2.update时,会将需要修改的数据页(dp_01,LSN=101),加载到data buffer中
3.DBWR线程,会进行dp_01数据页修改更新,并更新LSN=102
4.LOGBWR日志写线程,会将dp_01数据页的变化+LSN+TXID存储到redobuffer
5. 执行commit时,LGWR日志写线程会将redobuffer信息写入redolog日志文件中,基于WAL原则,
在日志完全写入磁盘后,commit命令才执行成功,(会将此日志打上commit标记)
6.假如此时宕机,内存脏页没有来得及写入磁盘,内存数据全部丢失
7.MySQL再次重启时,必须要redolog和磁盘数据页的LSN是一致的.但是,此时dp_01,TXID=tx_01磁盘是LSN=101,dp_01,TXID=tx_01,redolog中LSN=102
MySQL此时无法正常启动,MySQL触发CSR.在内存追平LSN号,触发ckpt,将内存数据页更新到磁盘,从而保证磁盘数据页和redolog LSN一值.这时MySQL正长启动
以上的工作过程,我们把它称之为基于REDO的"前滚操作"

undo
回滚日志.
作用: 在 ACID特性中,主要保证A的特性,同时对CI也有一定功效

(1)记录了数据修改之前的状态
(2)rollback 将内存的数据修改恢复到修改之前
(3)在CSR中实现未提交数据的回滚操作
(4)实现一致性快照,配合隔离级别保证MVCC,读和写的操作不会互相阻塞

锁
实现了事务之间的隔离功能,InnoDB中实现的是行级锁.
row-level lock
gap
next-lock

隔离级别
RU : 读未提交,可脏读,一般部议叙出现
RC : 读已提交,可能出现幻读,可以防止脏读.
RR : 可重复读,功能是防止"幻读"现象 ,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR : 可串行化,可以防止死锁,但是并发事务性能较差
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,一般在为了读一致性会在正常select后添加for update语句.但是,请记住执行完一定要commit 否则容易出现所等待比较严重.

transaction_isolation=read-uncommitted
transaction_isolation=read-committed
transaction_isolation=REPEATABLE-READ
MVCC —> undo 快照

RU 会出现脏读 ,
RC 会出现不可重复读 ,也会出现幻读.
RR 通过MVCC基础解决了不可重复读,但是有可能会出现幻读现象
在RR模式下,GAP和Next-lock进行避免幻读现象,必须索引支持