MySQL更新SQL执行，undoLog、redoLog、binLog三宝如何协同工作？

前言：一条update背后的血泪史

先说一句， 写代码的兄弟们，你们有没有在深夜里敲下那句update user set name='Lading' where id=1;后来啊第二天醒来发现数据库崩了？这不是玄幻，而是undo、redo、binlog三宝在暗暗作祟。

别急， 先给你来点情绪调味剂——我昨晚熬夜堪完LOL S14，Bin哥那场翻盘让我泪流满面后来啊第二天早上我的MySQL也跟着翻车， 至于吗？ 日志三宝不齐全导致数据丢失。于是我决定把这段血泪写成文，让大家别再踩坑。

一、 客户端发起UPDATE——惊慌失措的第一步

客户端把SQL塞进网络层，MySQL的解析器像个冲锋陷阵的骑士，先把语法拆开，再交给优化器。优化器一路狂奔，把施行计划喂给存储引擎。此时你根本不知道下面的日志三宝以经开始排队等候，闹笑话。。

二、 InnoDB Buffer Pool：数据的临时避难所

所you的数据页先被拽进buffer pool——它像个巨大的地下仓库， 有啥说啥... 里面堆满了数据块、索引块，还有一摞摞待命的日志缓冲。

如guo目标行以经在buffer里 那直接上锁；不在的话，就去磁盘挑出对应页装进来染后才敢动手改值，C位出道。。

三、 undoLog——“事前预警”日志

摆烂。 改动之前，InnoDB会把旧值偷偷写进undo log这一步就像是给自己留后路：事务回滚时可依凭它把原样恢复。

注意：undo log只保存在内存里的undo buffer接着才会刷到磁盘。如guo系统突发宕机，这块缓存可嫩全军覆没，痛并快乐着。。

四、 redoLog——“事后补救”日志

新值写进buffer pool后紧接着生成redo log记录的是修改后的新值和对应的数据页地址。