上一篇文章中,我们了解了一条查询语句的执行过程,按理说这篇应该讲一条更新语句的执行过程,但这个过程比较复杂,涉及到了好几个日志与事物,所以先梳理一下3个重要的日志,bin log(归档日志)、redo log(重做日志)、undo log(回滚日志)
概括
MySQL中有六种日志文件，分别是：重做日志（redo log）、回滚日志（undo log）、二进制日志（bin log）、错误日志（error log）、慢查询日志（slow query log）、一般查询日志（general log），中继日志（relay log）。
其中bin log和undo log与事务操作息息相关,bin log也与事务操作有一定的关系，这三种日志，对理解MySQL中的事务操作有着重要的意义。
接下来,分别对3种日志做总结概括
bin log
是个啥
由Mysql的Server层实现,是逻辑日志,记录的是sql语句的原始逻辑，比如"给 ID=2 这一行的C字段加1"
怎么工作的
binlog会写入指定大小的物理文件中,是追加写入的,当前文件写满则会创建新的文件写入。
产生:事务提交的时候,一次性将事务中的sql语句,按照一定的格式记录到binlog中。
清理:可设置参数expire_logs_days,在生成时间超过配置的天数之后,会被自动删除。
有啥用
1.用于复制,在主从复制中，从库利用主库上的binlog进行重播(执行日志中记录的修改逻辑),实现主从同步。
2.用于数据库的基于时间点的还原。
3种记录模式
statement：基于SQL语句的模式，某些语句中含有一些函数，例如 UUID,NOW 等在复制过程可能导致数据不一致甚至出错。
row：基于行的模式，记录的是行的变化,很安全。但是 binlog 的磁盘占用会比其他两种模式大很多,在一些大表中清除大量数据时在 binlog 中会生成很多条语句,可能导致从库延迟变大。
mixed：混合模式,根据语句来选用是 statement 还是 row 模式。表结构变更使用 statement 模式来记录,如果 SQL 语句是 update 或者 delete 语句,那么使用row模式。
redo log
是个啥
由引擎层的InnoDB引擎实现,是物理日志,记录的是物理数据页修改的信息,比如"某个数据页上内容发生了哪些改动"
怎么工作的
原理:当一条数据需要更新时,InnoDB会先将更新操作记录到rodolog中,并更新到内存中,这个更新就算是完成了。InnoDB引擎会在mysql空闲时将这些更新操作更新到磁盘中(数据文件)。
(这个就是MySql经常说到的WAL技术,Write-Ahead Logging ,关键点是先写日志,再写磁盘)
存储:redolog是顺序写入指定大小的物理文件中的。是循环写入的,当文件快写满时,会边擦除边刷磁盘,即擦除日志记录(redolog file)并将数据刷到磁盘中。
有啥用
1.提供crash-safe 能力(崩溃恢复),确保事务的持久性。
数据库突然崩溃,有些数据并未刷到数据文件中,当重启MySQL数据库,会从redolog中未刷到磁盘的数据刷到磁盘中。
2.利用WAL技术推迟物理数据页的刷新，从而提升数据库吞吐，有效降低了访问时延。
undo log
是个啥
由引擎层的InnoDB引擎实现,是逻辑日志,记录数据修改被修改前的值,比如"把Name=‘B’ 修改为Name = ‘B2’ ，那么undo日志就会用来存放Name='B’的记录"
怎么工作的
当一条数据需要更新前,会先把修改前的记录存储在undolog中,如果这个修改出现异常,则会使用undo日志来实现回滚操作,保证事务的一致性。
当事务提交之后，undo log并不能立马被删除,而是会被放到待清理链表中,待判断没有事物用到该版本的信息时才可以清理相应undolog。
有啥用
保存了事务发生之前的数据的一个版本，用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
3种日志在事物执行过程中的工作
分别总结很难看出在sql执行过程中这3个日志是如何工作的,现在我们把它们都放到一个事务中。
user表id name1 ken2 river
BEGIN update name = 'wk' from user where id = 1update name = 'river' from user where id = 2commit
实际事物的执行顺序如下:
A.将id=1的行name的值读取到内存中
B.记录id=1的行name=ken到undo log
C.修改name=wk
D.记录相应数据页的修改到redo log,并更新内存中的数据
E.将id=2的行name的值读取到内存中
F.记录id=2的行name=lj到undo log
G.修改name=lj
H.记录相应数据页的修改到redo log,并更新内存中的数据
I.记录事务中所有SQL的逻辑操作到bin log
J.提交事务
K.MySql服务器空闲时,把redo log中的物理数据页刷到磁盘数据文件中
1.保证原子性:更新数据前,记录undo log,为保证在更新数据时发生异常导致更新失败,这时可以使用undo log对数据进行回滚(回滚内存中的数据,并会在redo log中记录回滚操作)
2.保证持久性:每更新数据后,记录redo log,为防止服务器突然宕机,导致没有把数据刷到磁盘中,每次重启MySql服务器都会从redo log将脏页(未能及时写到磁盘的数据页)刷到磁盘
3.两阶段提交,保证数据的一致性:
先写redo log,再写bin log,完成后才能认为事务是完整的。从库主要通过bin log进行同步,但如果服务器异常宕机,可能会造成主从数据不一致的情况。
a.写完redo log宕机,bin log还没写
因为两阶段提交机制,MySql会判断redo log 和 bin log是否都完整,如果不完整,则认为事务未提交,在从redo log 刷数据时,就不会刷未提交的事务的数据
b.在写bin log的中途宕机
已经写了部分的bin log,但是没有写完整（binlog 是否完整会有一个标识符标识），仍然认为事务未提交。崩溃恢复和主从复制时,都不会使用未提交的数据,从而实现数据的一致性。
c.bin log写完了,但未提交事务
两阶段提交机制认为,只要redo log和bin log都是完整的,则可以认为事务提交了。
总结
本篇文章只是简单的介绍bin log、redo log、undo log,更深层次的东西就不说了，我也不懂。希望这篇文章能帮到你理解MySql背后的事务。
