MySQL日志

关键在于掌握undo-log、redo-log和bin-log的概念、作用、结构。

自己写的博客本质还是给自己看的（更是是自己输出的过程），所以从别人博客那里复制粘贴没必要。所以日志相关的内容，我这里写的更多的是理解性的，也比较浅。更深的、系统性的见下面两篇博客：

https://xiaolincoding.com/mysql/log/how_update.html

https://juejin.cn/post/7157956679932313608

Undo-log

Undo-log，回滚日志，是用于保证事务ACID性质中原子性的日志；另外还有个作用，MVCC（多版本控制）通过Read View + Undo log日志来实现（因为回滚日志能形成记录的版本链）。

为什么说undo log保证了原子性呢？而且一条普通的更新语句也不是事务呀？其实autocommit参数默认开启，所以执行一条update语句也是开启事务的。其次就是如何保证原子性的——假设一个事务执行失败，由于undo log日志有旧版本的数据信息，所以事务回滚后能将数据恢复到事务执行前的样子，这就保证了事物的原子性（同时失败）。

具体来说，undo log里记录数据时会有两个隐藏列——trx_id，用于表示该版本数据是哪个事务修改后的，roll_ptr，用于指向上一个版本的数据（便于回滚或查看旧版本数据（变相支持了隔离性））。

Redo-log

Redo-log，重做日志，是用于保证事务ACID性质中持久性的日志。

为什么说redo log保证了持久性呢？因为InnoDB在插入一条数据时，会先将这条新数据写入到redo log中，之后后台进程再去把redo log中的脏页数据刷入硬盘。

那为什么不直接把数据写入硬盘中而是要使用redo log呢？主要是出于性能方面考虑，以及在MySQL服务宕机后有更好的恢复效果。如果是直接写入数据，那么要找到数据在硬盘中的物理地址后再写入，属于随机存储，而写入redo log就是直接在指定位置后面顺序写入，效率更高，所以写入redo log直接返回客户端“数据已成功写入”，这样的响应时间更短。（后续把真实数据写入硬盘有专门的异步线程来做）。那么在没有把redo log中的数据写入硬盘呢，MySQL服务就宕机了，也没关系，redo log已经写入了数据缓存页，那等MySQL服务恢复后就能把数据写入。（如果是redo中都没写入就宕机……那么sql就没执行成功，也返回给服务端成功的提示，所以问题不大）

实际上InnoDB在Buffer Pool（缓冲池）中，不仅缓存了数据页、索引页，还有插入缓存页、undo页等信息。也就是有redo log的缓存（所以redo log可以选择不是每次事务提交都刷盘）——这个可以通过redo log相关参数来配置刷盘策略。

why？每次刷盘和先放在缓存再一次刷入，前者保证数据的持久性，后者提高性能（减少IO次数），各有利弊，看实际而权衡。（默认策略是事务提交就刷盘）

关于redo log的结构，默认有两个日志文件，然后进行循环写。