读书心得笔记：500多年前，王阳明龙场悟道豁然开朗，致良知，吾心光明！这句话掷地有声、回响千年不绝，开启华夏心学新篇章。为天地立心，为生民立命，为往圣继绝学，为万世开太平。如此沉重伟大的理想，此时此刻王阳明心里终于找到了答案。
一、前言背景
二、客户端发起update SQL更新
三、存储引擎InnoDB-数据缓存池Buffer pool
四、undoLog-记录更新前数据
五、redoLog-记录更新后数据
5.1 redolog的刷盘策略
六、binLog-MySQL server服务逻辑日志
6.1 binlog的刷盘策略
6.2 binLog和redoLog一起完成事务提交
七、后台IO线程更新缓存数据落盘
一、前言背景
每次看到binLog几个字，让我想起今年LOL S14，熬夜看完BLG2:3痛失冠军比赛，印象最深感觉最可惜的上单Bin哥。之前解说记得说过：天不生TheShy，LPL上单万古无长夜！现如今的Bin哥，个人觉得是Shy哥之后：天不生Bin，LPL上单万古无长夜！能抗能C，还能1 vs N拿到头还不死，这样的团队大核，值得登顶世界第一上单！期待S15，Shy哥回归，与Bin哥的精彩对局。抱歉，扯远了！
上一篇文章，我们对MySQL整体架构有了初步了解，今天我们深入了解核心存储引擎相关要点，主角就是undoLog、redoLog、binLog日志三宝。通过一条更新sql执行过程，来详细了解这三种日志的生成，以及结合一些故障场景了解他们的意义。掌握底层原理过程，对深入掌握MySQL存储引擎和面试跳槽极其重要！
二、客户端发起update SQL更新
我们有一条更新SQL，目标是更新id为1的数据name为lading01：
update user set name='lading01' where id =1;
如下图，SQL从客户端到达MySQL接口、解析器、优化器、存储引擎。接下来存储引擎如何执行更新？
三、存储引擎InnoDB的核心-数据缓存池Buffer pool
不管是查询sql or 更新sql来到存储引擎，都要应用存储引擎的数据缓存池buffer pool。update sql也是先检查缓存池，看目标数据是否在缓存池里，如果存在，就加锁去更新缓存。如果数据不在buffer pool，就先从磁盘找找到对应数据页加载到缓存池，再加锁更新。buffer pool是核心中的核心，后面会出一篇专门讲里面的数据结构、刷数策略、冷热数据链处理逻辑等内容。
buffer pool很强大，可以说InnoDB的所有数据缓存都在这。但传统意义，大家喜欢把数据、索引、锁缓存数据作为buffer pool的唯一数据，这种理解划分其实仁者见仁没有对错。为了方便大家理解和分享，今天三宝undo、redo、binlog也单独画缓存图。
四、undoLog-记录更新前数据
undoLog有的称为回滚日志、撤销日志，或者修改前日志。我更喜欢用【操作前数据日志】来定义undoLog。undoLog的意义，在于用来回滚数据。尤其是事务还没提交，需要做回滚，就可以通过undoLog来回滚。不管是新增insert、还是delete删除、或者update更新，undoLog都可以记录到操作前的数据，确保可以进行有效回滚。
undoLog，在缓存池中也有自己的缓存，undoLog buffer，最终持久数据默认存储在xx.ibdata文件中。这里具体可以理解为：update sql就记录修改前值，delete删除的话就记录被删除数据信息，而insert新增就生成对应的delete。
在把id=1数据加载到缓存池后，先把修改前值，写入到undoLog日志。最后更新id=1的数据缓存。步骤如图：
undoLog除了做事务回滚，在MVCC多版本控制起了关键作用。
五、redoLog-记录更新后数据
在将新值更新到buffer pool后，以及记录数据旧值到undoLog，此时出现了一个问题：磁盘数据和缓存是不一致，磁盘里的数据还没被及时更新。假如其他一切正常，服务器宕机或者MySQL服务异常下线，就导致缓存里的新值无法被记录到磁盘里。
这时候，redoLog出现了。在经过1、2、3，记录完修改前值，并更新了缓存数据，还需要记录修改后新值的redoLog日志数据。「拉丁解牛说技术，实用至上，坚持用最简洁直白的文字+最少的代码示例分享干货。」
redoLog的作用和undoLog很像，它是负责支持MySQL异常宕机后，用来恢复修改后未被及时写入磁盘的缓存数据。
5.1 redolog的刷盘策略
MySQL高效的读写效率很大一部分在于存储引擎缓存的优秀设计。在数据更新、undo、redoLog的更新，都是先直接更新内存，这样效率非常高。但是这样就需要研发认真考虑，缓存数据什么时候需要刷盘写入磁盘文件。
redoLog从内存更新到磁盘专门有一个参数：【innodb_flush_log_at_trx_commit】控制。具体如下：
innodb_flush_log_at_trx_commit=0： 表示每次事务提交时都只是把 redo log 留在 redo log buffer 。
innodb_flush_log_at_trx_commit=1： 表示每次事务提交时都将 redo log 直接持久化到磁盘，
innodb_flush_log_at_trx_commit=2： 表示每次事务提交时都只是把 redo log 写到系统 page cache，这个缓存大概1s左右刷一次到磁盘。
面对MySQL宕机，具体分析：
当提交事务后，如果innodb_flush_log_at_trx_commit=0，MySQL宕机了，undoLog丢失，就导致数据丢失。
当提交事务后，如果innodb_flush_log_at_trx_commit=1，MySQL宕机了，undoLog已经写到磁盘，系统恢复后，从redolog恢复最新更新值。
当提交事务后，如果innodb_flush_log_at_trx_commit=2，MySQL宕机了，undoLog由于仅存在系统缓存，如果很不幸，存在os cache数据没来得及刷入磁盘redoLog日志，此时也会出现数据丢失。
所以，对数据一致性和数据丢失0容忍的业务场景，必须选择innodb_flush_log_at_trx_commit=1。确保事务提交时，redoLog都已经持久化到磁盘存储，确保MySQL服务下线、或者服务器宕机都不会出现数据丢失。
六、binLog-MySQL Server服务逻辑日志
在了解了undoLog、redoLog两兄弟后，一个用来做回滚、一个用来做数据恢复，承担的数据功能各有不同。而我们常说的MySQL事务确保数据不丢失，很大功劳就是redoLog日志。
如此看来，update sql在数据修改前、后，都得到了很好的保障。为什么还需要binLog? binLog有什么作用？
「拉丁解牛说技术，实用至上，坚持用最简洁直白的文字+最少的代码示例分享干货。」
MySQL作为一个完整的系统服务，也需要自己的日志。undoLog、redoLog更多是存储引擎在做数据变更前后的日志记录。从整体来说，存储引擎只是MySQL系统的一个组件。而binLog的正是MySQL系统的数据行为逻辑日志。
binLog内容（全称binary log）是二进制内容，类似日常开发主动打印的log.info日志，比如：MySQL接受update SQL请求，binLog会记录下xx在什么时候，对id=1这行数据进行更新，更新值为lading01，主要用于数据恢复和主从复制。而redo、undoLog属于数据物理数据日志，日志内容类似在磁盘数据页地址0xada421的4kb的数据区xxx，修改了新值xx。
很明显，binLog是所有MySQL都有的通用逻辑日志，而undo、redoLog日志，属于存储引擎InnoDB的日志，属主不一样，意义格式内容也不一样。
当更新SQL提交事务，redoLog记录完后，也要记录binLog日志，默认是binLog的数据写到os 缓存，具体如下步骤5：
6.1 binlog的刷盘策略
MySQL有个参数【sync_binlog】专门用来控制提交事务时binLog的刷盘策略。具体策略如下：
sync_binlog=0，默认就是0，表示每次提交事务都只写到os cache,不 fsync。这种情况如果MySQL服务器突然宕机，存在os cache没来得及被刷到磁盘的，就可能出现binlog日志丢失情况。
sync_binlog=1，表示每次提交事务都会执行 fsync，binLog必须落地到磁盘。也就是事务提交，binLog已经完成持久化到磁盘，数据不会丢失。
sync_binlog=N(N>1) ,表示每次提交事务都 write，但累积 N 个事务后才 fsync。
6.2 binLog和redoLog一起完成事务提交
在redoLog物理日志落盘、binLog逻辑日志落盘时候，这里有个细节。本次更新写到binlog文件的位置、会同步写到redoLog文件里并加上commit标识在redoLog，表示该事务提交真正完成，如下图第6步骤。这么做的意义是什么呢？
答案：确保数据层级的日志+服务层的日志，在事务提交时能保持一致。具体分析：
假如在步骤4完成后，系统挂了，由于binLog为落盘，所以本次事务提交不算完成，属于事务提交失败。
假如在步骤5完成后，系统挂了，由于binLog、redoLog都落盘，但是没回写记录commit到redoLog，本次事务不算完成，属于事务提交失败。
假如在步骤6完成后，系统才挂，这时候，redoLog、binLog、以及redoLog记录了commit标识，本次事务得到完整记录，事务提交成功。系统重启后，可以恢复该事务数据。
基于这个设计，10年前我们在用kafka 0.7、0.8版本的时候，在消费topic数据时，为了在kafka-client记录消费数据的offset，我也参考过这个思想，在落地消费数据的时候，也将offset持久化到磁盘。确保本次消费事务提交前，日志和数据都已经落地。
七、后台IO线程更新缓存数据落盘
当MySQL的日志三宝都落盘后，缓存池里的最新数据，什么时候落盘？MySQL设计专门的线程负责不定时去把缓存里的最新数据更新到磁盘，这里深入说也比较复杂，今天篇幅有限，等下一篇深入分享。
推荐阅读拉丁解牛相关专题系列(欢迎交流讨论公众号搜：拉丁解牛)：
2、JVM进阶调优系列(2)字节面试:JVM内存区域怎么划分，分别有什么用？
4、JAVA并发编程系列(13)Future、FutureTask异步小王子
