我有一个老朋友，咱们叫他熊猫。发际线及将触碰到后脑勺，大框金丝眼镜也覆盖不住那黝黑的眼圈，显得分外的“程序员”；衣着也十分不拘一格，上半身是衬衣西服，下半身是牛仔裤配拖鞋~

我和熊猫的感情很好，毕业后他去了上海而我开始北漂，但每次过节回老家我俩都会和敌人们一起吃饭，这次回家过年也不例外。这次，咱们敌人几个去了枣庄闻名的“好再来土菜馆”，点了特色的枣庄辣子鸡，超大盘那种。

这次在饭桌上，咱们聊到了疫情期间咱们几个踊跃加入各大厂收费面试的一些乏味场景。熊猫说在面试一家数据存储的大厂时，深挖了一个MySQL问题，redo log和 binlog，很有意思。另外，MySQL 系列面试题和答案全副整顿好了，微信搜寻Java技术栈，在后盾发送：面试，能够在线浏览。

面试官也很客气，总有种莫名的亲切感。说着，翘起二郎腿喊道：“老板，再来一箱青岛”！咱们几个都晓得，熊猫又要开始回放了~~

以下是熊猫和面试官马经理的对话。

熊猫：马…小马哥好！

面试官：额…你好，小李啊，看你简历写着精通MySQL事务、日志原理，你认为精通应该是啥程度呢？

熊猫（老脸一红）：emmm…精通就是，比面试官晓得的多一点呗。。

面试官：（嗯。。。。是个老实人，我喜爱！）

面试官：那你先给我讲讲MySQL里有哪些比拟重要的日志吧？

熊猫：（我只看了redo log、binlog面试题，咋整，多说会不会给本人挖坑？记得鲁迅大爷说过：别啥JB都说，最初坑本人）

熊猫：嗯。。其实MySQL中的日志有很多，但日常接触最多的是重做日志（redo log）、归档日志（binlog）这两种，当然还有回滚日志（undo log）等等，我接触的少一些。

MySQL日志次要包含六种：

  1. 重做日志（redo log）
  2. 回滚日志（undo log）
  3. 归档日志（binlog）
  4. 谬误日志（errorlog）
  5. 慢查问日志（slow query log）
  6. 个别查问日志（general log）
  7. 中继日志（relay log）

面试官：好，那你先说一下你对 redo log 日志的了解吧。

熊猫：记得小时候看《武林外传》，吕秀才柜台上面有一个小黑板，过后不晓得是干啥的，起初发现是专门用来记录客人的赊账记录。如果赊账的人不多，那么他能够把顾客名和账目写在板上。但如果赊账的人多了，小黑板没地儿了，这个时秀才肯定还有一个专门记录赊账的账本。如果有人要赊账或者还账的话，秀才个别有两种做法：

  • 一种做法是间接把账本翻出来，把这次赊的账加上去或者扣除掉；
  • 另一种做法是先在小黑板上记下这次的账，等打烊当前再把账本翻出来核算。

在生意火爆时，秀才必定会抉择后者，因为间接记账本太麻烦了。得先翻出赊账人“老钱”那条记录，账本稀稀拉拉几十页，找到后再拿出算盘计算，最初更新到账本上。

想想都麻烦。相比之下，还是先在小黑板上记一下不便。你想想，如果秀才没有小黑板的帮忙，每次记账都得翻账本，效率是不是低得让人难以忍受？还有工夫泡小郭？想无双？

同样，在 MySQL 里也有这个问题，如果每一次的更新操作都须要写进磁盘，而后磁盘也要找到对应的那条记录，而后再更新，整个过程 IO 老本、查找老本都很高。为了解决这个问题，MySQL 的设计者就用了相似秀才记小黑板的思路来晋升更新效率。

而小黑板和账本配合的过程，其实就是 MySQL 里常常说到的 WAL 技术。

面试官：小伙子你这思路很奇异呀！那你再具体跟我说一下，啥是WAL技术？

熊猫：（小马哥对我有意思啊！）

WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写小黑板，等不忙的时候再写账本。

具体来说，当有一条update语句要执行的时候，InnoDB 引擎就会先把记录写到 redo log（小黑板）外面，并更新内存，这个时候更新就算实现了。

同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘外面，而这个更新往往是在零碎比拟闲暇的时候做，这就像打烊当前秀才做的事。如果明天赊账的不多，掌柜能够等打烊后再整顿。

但如果某天赊账的特地多，小黑板写满了咋办？这个时候秀才只好叫无双帮忙干本人的活儿，放松把小黑板中的一部分赊账记录更新到账本中，而后把这些记录从小黑板上擦掉，为记新账腾出空间。

与此相似，InnoDB 的 redo log 是固定大小的，比方能够配置为一组 4 个文件，每个文件的大小是 100MB，那么这块“小黑板”总共就能够记录 400MB 的操作记录。从头开始写，写到开端就又回到结尾循环写，如上面这个图所示。

  • write position 是以后记录的地位，一边写一边后移，写到第 3 号文件开端后就回到 0 号文件结尾。
  • checkpoint 是以后要擦除的地位，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

write position 和 checkpoint 之间的是“小黑板”上还空着的局部，能够用来记录新的操作。

如果 write pos 追上 checkpoint，示意“小黑板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推动一下。

有了 redo log，InnoDB 就能够保障即便数据库产生异样重启，之前提交的记录都不会失落，这个能力称为 crash-safe。

crash-safe：
能够对照后面赊账记录的例子。只有赊账记录记在了小黑板上或写在了账本上，即便秀才忽然被老邢抓走几天，回来后仍然能够通过账本和小黑板上的数据明确赊账账目。就是保护数据的持久性。

实质上说，crash-safe 就是落盘解决，将数据存储到了磁盘上，断电重启也不会失落。

面试官：不错，你这了解虽说听的我一愣一愣，然而话糙理不糙，的确说出了redo log的原理。那你再说说对binlog日志的了解吧。

熊猫：嘿嘿，谢谢马经理夸赞。MySQL 其实是分为 server层 和 引擎层两局部。

  • Server 层：它次要做的是 MySQL 性能层面的事件；
  • 引擎层：负责存储相干的具体事宜。

下面咱们聊到的“小黑板” redo log 是 InnoDB 引擎特有的日志，而 Server 层也有本人的日志，称为binlog（归档日志），其实就是用来复原数据用的。

面试官：那MySQL为啥要有redo log 和 binlog两个日志呢？只留一个不香么？

熊猫：因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，然而 MyISAM 没有 crash-safe 的能力，而 binlog 日志只用于归档。

InnoDB 是另一个公司以插件模式引入 MySQL 的。咱们晓得，只依附 binlog 是没有 crash-safe 能力的，所以 InnoDB 应用另外一套日志零碎——也就是 redo log 来实现 crash-safe 能力。

面试官：那这两个日志次要有哪些区别？

熊猫：emmm…次要有几下几种区别：

  1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎共用。
  2. redo log 是物理日志，记录的是“在某个数据页上做了什么批改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比方“给 ID=1 这一行的 c 字段加 1 ”。
  3. redo log 是循环写的，空间固定会用完而后复写；binlog 是能够追加写入的。“追加写”是指 binlog 文件写到肯定大小后会切换到下一个，并不会笼罩以前的日志。

面试官：好，基于你下面说的，那比方上面这条SQL，你来形容一下在MySQL外部的执行流程吧

update T set money = money + 500 where username = '陈哈哈';

熊猫：

  1. （开始，原始数据接入）执行器先找引擎取 username = ‘陈哈哈’ 这一行。如果 username = ‘陈哈哈’ 这一行所在的数据页原本就在内存中，就间接返回给执行器；否则，须要先从磁盘读入内存，而后再返回。
  2. （数据批改）执行器拿到引擎给的行数据，把 money 这字段的值加上 500，比方原来是 N，当初就是 N+500，失去新的一行数据，再调用引擎接口写入这行新数据。
  3. （数据提交）提交操作，因为存储引擎层与server层之间采纳的是外部XA(保障两个事务的一致性,这里次要保障redo log和binlog的原子性)，所以提交分为prepare阶段与commit阶段，也就是咱们说的两阶段提交。
  4. （写redo log）引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 外面（写到内存或间接落盘），到这里， redo log 处于 prepare 状态。
  5. （写binlog）而后告知执行器执行实现了，随时能够提交事务。执行器生成这个操作的 binlog，并把 binlog 同步到磁盘。
  6. （数据更新到磁盘或内存，完结）执行器调用引擎的提交事务接口执行批改操作，须要将在二级索引上做的批改，写入到change buffer page，等到下次有其余sql须要读取该二级索引时，再去与二级索引做merge，引擎把刚刚写入的 redo log 标记上（commit）状态，实际上是加上了一个与binlog对应的XID，使两个日志逻辑保持一致，到此结束，更新流程闭环。

面试官：那为啥必须要分成prepare和commit两个阶段进行提交呢？一块儿提交他不爽么。

熊猫：我举个现实生活中的栗子吧，一个残缺的交易过程我认为应该这样：

比方你来我的小超市里买一瓶可乐：

  1. 小马哥：老板给我来瓶可乐！透心凉心飞腾的那个。
  2. 我：？？
  3. 机器扫一下可乐，通知小马哥这瓶可乐2块5，不能白嫖，让他给钱（记录 redo log，事务处于prepare状态）
  4. 收钱放入钱箱（记录 binlog，事务理论是否实现的基本根据，处于待标记commit阶段）
  5. 而后让你把可乐拿走（redo log 状态标为 commit，示意该事务逻辑闭环）。到这里，代表一笔交易完结。
  6. 并通知小马哥，透心凉心飞腾那个是雪碧，你个憨X~
  7. 等算账前再把这一天卖东西的交易信息一起同步到数据库。

可见，如果收钱之前（prepare阶段，步骤3）交易被打断，回过头来解决此次交易，发现只有记了小黑板但没有收钱，则交易失败，删掉小黑板上的记录（回滚）；

如果收了钱后（commit阶段 或 待commit阶段，步骤4 || 5）交易被打断，而后回过头发现零碎上有记录（prepare）而且钱箱有本次支出（bin log），则阐明本次交易无效，补充批改commit状态，更新到库存中。

以上是人话，咱们再来看看MySQL层面的业余解释：

这里咱们用反证法来进行解释为何须要两阶段提交。因为 redo log 和 binlog 是两个独立的逻辑，如果不必两阶段提交，要么就是先写完 redo log 再写 binlog，或者采纳反过来的程序。咱们看看这两种形式会有什么问题。

依然用后面的 update 语句来做例子。假如以后 username = ‘陈哈哈’ 的行，账户余额字段 money 的值是 100，再假如执行 update 语句过程中在写完第一个日志后，第二个日志还没有写完期间产生了 crash（异样宕机），会呈现什么状况呢？

仍旧以这条SQL为例：

update T set money = 0 + 500 where username = '陈哈哈';

1、先写 redo log 后写 binlog。

假如在 redo log 写完，binlog 还没有写完的时候，MySQL 过程异样重启。因为咱们后面说过的，redo log 写完之后，零碎即便解体，依然可能把数据恢复回来，所以复原后这一行 money 的值是 money + 500。

然而因为 binlog 没写完就 crash 了，这时候 binlog 外面就没有记录这个语句。因而，之后备份日志的时候，存起来的 binlog 外面就没有这条语句。

而后你会发现，如果须要用这个 binlog 来复原长期库的话，因为这个语句的 binlog 失落，这个长期库就会少了这一次更新，复原进去的这一行 money 的值就是 0，与原库的值不同。

2、先写 binlog 后写 redo log。

如果在 binlog 写完之后 crash，因为 redo log 还没写，解体复原当前这个事务有效，用户余额 money 的值该当是 0。

然而 binlog 外面曾经记录了“把 money 从 0 改成 500 这个日志。所以，在之后用 binlog 来复原的时候就多了一个事务进去，复原进去的这一行 money 的值就是 500，与原库的值不同。

能够看到，如果不应用“两阶段提交”，那么数据库的状态就有可能和用它的日志复原进去的库的状态不统一。

简略说，redo log 和 binlog 都能够用于示意事务的提交状态，而两阶段提交就是让这两个状态放弃逻辑上的统一。

日志落盘

保障事务胜利，日志必须落盘，这样，数据库crash后，就不会失落某个事务的数据了

  • innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，示意每次事务的 redo log 都间接长久化到磁盘。这样能够保障 MySQL 异样重启之后数据不失落。
  • sync_binlog 这个参数设置成 1 的时候，示意每次事务的 binlog 都长久化到磁盘。这样能够保障 MySQL 异样重启之后 binlog 不失落。

面试官：（老脸一红）

面试官：小李，坦白说我也很久没搞技术了，但我感觉你的确很懂这块儿，为什么？因为你把我都给我干困了。。我很观赏你吹…讲故事的能力，你，你懂我意思吧。

面试官：小李啊，你等我一会儿。（马经理提着裤子走出了办公室）

熊猫：（尿遁了？？不应该啊，我这波操作难道还不香么？难道，被识破了？？-_-’’|）

五分钟后HR来了。。

HR：小李，我就说你行吧！！领导很看好你，说你表白思路奇异，很合乎这个岗位，并给你点了个赞，让我告诉你下周来入职吧。

熊猫：好的好的，看来当初开发对表达能力要求还挺高啊~~

HR：？？兄弟不是应聘产品么？

熊猫：你跟我俩搁这儿扯犊子呢？我应聘的软件开发工程师大哥？

HR：（嗯，看来果然是我打错面试电话了。。沉着沉着，小问题）

HR：好的，那明天就先这样，回去等告诉吧 还有啥问题要问我么？

熊猫：。。。。。

总结

好了，明天咱们理解了 MySQL 外面最重要的两个日志，即物理日志 redo log 和逻辑日志 binlog。另外，MySQL 系列面试题和答案全副整顿好了，微信搜寻Java技术栈，在后盾发送：面试，能够在线浏览。

为该讲的内容总结了几个问题, 大家温习的时候能够先尝试答复这些问题查看本人的把握水平。

  1. redo log的概念是什么? 为什么会存在.
  2. 什么是WAL(write-ahead log)机制, 益处是什么.
  3. redo log 为什么能够保障crash safe机制.
  4. binlog的概念是什么, 起到什么作用, 能够做crash safe吗?
  5. binlog和redolog的不同点有哪些?
  6. 物理一致性和逻辑一致性各应该怎么了解?
  7. 执行器和innoDB在执行update语句时候的流程是什么样的?
  8. 如果数据库误操作, 如何执行数据恢复?
  9. 什么是两阶段提交, 为什么须要两阶段提交, 两阶段提交怎么保障数据库中两份日志间的逻辑一致性(什么叫逻辑一致性)?
  10. 如果不是两阶段提交, 先写redo log和先写bin log两种状况各会遇到什么问题?

原文链接：https://blog.csdn.net/qq_3939...

版权申明：本文为CSDN博主「_陈哈哈」的原创文章，遵循CC 4.0 BY-SA版权协定，转载请附上原文出处链接及本申明。

近期热文举荐：

1.1,000+ 道 Java面试题及答案整顿(2021最新版)

2.别在再满屏的 if/ else 了，试试策略模式，真香！！

3.卧槽！Java 中的 xx ≠ null 是什么新语法？

4.Spring Boot 2.5 重磅公布，光明模式太炸了！

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！