敞开生长之旅！这是我参与「日新计划 12 月更文挑战」的第15天，点击查看活动概况

上一篇文章说完MySQL的业务和锁了，这次来详细介绍一下在MySQL中一条更新句子的详细履行流程 (本文无特殊说明均是选用Innodb存储引擎)。

前期准备

⭐⭐首要创建一张表，然后插入三条数据：

CREATE TABLE T(
    ID int(11) NOT NULL AUTO_INCREMENT,
    c int(11) NOT NULL,
    PRIMARY KEY (ID)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='测试表';
​
INSERT INTO T(c) VALUES (1), (2), (3);

让后履行更新操作：

update T set c=c+1 where ID=2;

在说更新操作前，咱们先来看一下sql句子在MySQL中的履行流程~

SQL句子的履行进程

如图所示：MySQL数据库主要分为两个层级：服务层和存储引擎层服务层：[server层包括]{.blue}：衔接器、查询缓存、剖析器、优化器、履行器，包括大多数MySQL中的核心功用一切跨存储引擎的功用也在这一层完成，包括 存储进程、触发器、视图等。 [存储引擎层]{.purple}：存储引擎层包括MySQL常见的存储引擎，包括MyISAM、InnoDB和Memory等，最常用的是InnoDB，也是现在MySQL的默认存储引擎。

server层中的组件介绍

  1. 衔接器✨： 需求MySQL客户端登录，需求一个 衔接器 来衔接用户和MySQL数据库，“mysql -u 用户名 -p 密码” 进行MySQL登录，在完结 TCP握手 后，衔接器会依据输入的用户名和密码验证登录身份。

  2. 查询缓存✨： MySQL在得到一个履行请求后，会首要去 查询缓存 中查找，是否履行过这条SQL句子，之前履行过得句子以及成果会以 key-value对的方式，放在内存中。key是查询句子，value是查询的成果。假如经过key能够查找到这条SQL句子，直接返回SQL的履行成果。若不存在缓存中，就会持续后面的履行阶段。履行完结后，履行成果就会被放入查询缓存中。长处是功率高。可是查询缓存不建议运用， 由于在MySQL中对某张表进行了更新操作，那么一切的查询缓存就会失效，关于更新频繁的数据库来说，查询缓存的命中率很低。需求注意：在MySQL8.0版别，查询缓存功用就删除了，不存在查询缓存的功用了

  3. 剖析器✨: 分为词法剖析和语法剖析

    • 词法剖析： 首要，MySQL会依据SQL句子进行解析，剖析器会先做 词法剖析，你写的SQL便是由多个字符串和空格组成的一条SQL句子，MySQL需求识别出里边的字符串是什么，代表什么。
    • 语法剖析： 然后进行 语法剖析， 依据词法剖析的成果，语法剖析器会依据语法规矩，判别输入的这个SQL句子是否满足MySQL语法。假如SQL句子不正确，就提示：You have an error in your SQL suntax

  4. 优化器✨： 经过剖析器剖析后，SQL就合法了，但在履行之前，还需求进行优化器的处理，优化器会判别运用了哪种索引，运用哪种衔接，优化器的效果 便是确定功率最高的履行计划。

  5. 履行器✨： 在履行阶段，MySQL首要会判别有没有履行句子的权限，若无权限，返回没有权限的过错；若有权限，就翻开表持续履行。翻开表时，履行器会依据标的引擎界说，去运用该引擎供给的接口，关于有索引的表，履行的逻辑相似。

了解完SQL句子的履行流程咱们接下来详细剖析一下上面update T set c=c+1 where ID=2;是怎么履行的。

Update句子剖析

update T set c=c+1 where ID=2;

在履行update更新操作的时分，跟这个表有关的查询缓存会失效，所以这条句子就会把表 T 上一切缓存成果都清空。接下来，剖析器会经过语法剖析和词法剖析，知道了这是一条更新句子后，优化器决议要运用哪一个索引，然后履行器担任具体的履行，先找到这一行，然后做更新。

依照咱们往常的思路，便是 找出这条记录，把它的值改好，保存就OK了 。但咱们追究一下细节，由于涉及到修改数据，所以涉及到日志了。更新操作涉及到两个重要的日志模块。redo log(重做日志)，bin log(归档日志)。MySQL中的这两个日志也是必学的。

redo log(重做日志)

  • 在 MySQL 里，假如每一次的更新操作都需求写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个进程 IO 本钱、查找本钱都很高。 MySQL里运用WAL(预写式日志)技术，WAL 的全称是 Write-Ahead Logging，它的要害点便是 先写日志，再写磁盘。
  • 具体来说，当有一条记录需求更新的时分，InnoDB 引擎就会先把记录写到 redo log里边，并更新内存，这个时分更新就算完结了。同时，InnoDB 引擎会在恰当的时分，将这个操作记录更新到磁盘里边，而这个更新往往是在体系比较闲暇的时分做。
  • InnoDB 的 redo log 是固定大小的，比方能够装备为一组 4 个文件，每个文件的大小是 1GB，那么一共就能够记录 4GB 的操作。从头开端写，写到末尾就又回到最初循环写。

听完上面临redo log日志的介绍后，小伙伴们可能会问：redo log日志存储在哪？， 数据库信息保存在磁盘上，redo log日志也保存在磁盘上，为什么要先写到redo log中再写到数据库中呢？，redo log日志假如存满数据了怎么办？等等。接下来就回答一下这些疑问。

redo log存储在哪里？

InnoDB引擎先把记录写到redo log 中，redo log 在哪，它也是在磁盘上，这也是一个写磁盘的进程， 可是与更新进程不一样的是，更新进程是在磁盘上随机IO，费时。 而写redo log 是在磁盘上次序IO。功率要高。

redo log 空间是固定，那它会不会用完呢？

首要不必担心 redo log 会用完空间，由于它是循环利用的。例如 redo log 日志装备为一组4个文件，每个文件分别为1G。它写的流程如下图：

简略总结一下: redo log日志是Innodb存储引擎特有的机制，能够用来应对反常康复，Crash-safe，redo能够确保mysql反常重启时，将未提交的业务回滚，已提交的业务安全落库。

crash-safe: 有了 redo log，InnoDB 就能够确保即便数据库产生反常重启，之前提交的记录都不会丢掉，这个才能称为crash-safe。

binlog(归档日志)

redo log是innoDB 引擎特有的日志。而binlog是mysql server层的日志。

其实bin log日志出现的时刻比redo log早，由于最开端MySQL是没有InnoDB存储引擎的，5.5之前是MyISAM。可是 MyISAM 没有 crash-safe 的才能，binlog 日志只能用于归档。而 InnoDB 是另一个公司以插件方式引进 MySQL 的，既然只依托 binlog 是没有 crash-safe 才能的，所以 InnoDB 运用别的一套日志体系——也便是 redo log 来完成 crash-safe 才能。

redo log和bin log的总结:

  • redo log是为了确保innoDB引擎的crash-safe才能，也便是说在mysql反常宕机重启的时分，之前提交的业务能够确保不丢掉；(由于成功提交的业务肯定是写入了redo log,能够从redo log康复)
  • bin log是归档日志，将每个更新操作都追加到日志中。这样当需求将日志康复到某个时刻点的时分，就能够依据全量备份+bin log重放完成。 假如没有敞开binlog,那么数据只能康复到全量备份的时刻点，而不能康复到任意时刻点。假如连全量备份也没做，mysql宕机，磁盘也坏了，那就很尴尬了。。

redo log和bin log的差异:

  • redo log 是 InnoDB 引擎特有的；bin log 是 MySQL 的 Server 层完成的，一切引擎都能够运用。
  • redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；bin log 是逻辑日志，记录的是这个句子的原始逻辑，比方“给 ID=2 这一行的 c 字段加 1 ”。
  • redo log 是循环写的，空间固定会用完；binlog 是能够追加写入的。“追加写”是指 binlog 文件写到必定大小后会切换到下一个，并不会覆盖曾经的日志。

InnoDB引擎部分在履行这个简略的update句子的时分的内部流程

update T set c=c+1 where ID=2;

手动用begin敞开业务，然后履行update句子，再然后履行commit句子，那上面的update更新流程之前 哪些是update句子履行之后做的，哪些是commit句子履行之后做的?

事实上，redo log在内存中有一个redo log buffer,binlog 也有一个binlog cache.所以在手动敞开的业务中，你履行sql句子，其实是写到redo log buffer和binlog cache中去的(肯定不行能是直接写磁盘日志，一个是性能差一个是回滚的时分不行能去回滚磁盘日志吧)，然后当你履行commit的时分，首要要将redo log的提交状况游prepare改为commit状况，然后就要把binlog cache刷新到binlog日志(可能也只是flush到操作体系的page cache，这个就看你的mysql装备)，redo log buffer刷新到redo log 日志(刷新机遇也是能够装备的)。 假如你回滚的话，就只用把binlog cache和redo log buffer中的数据清除就行了。

在update进程中，mysql忽然宕机，会产生什么情况?

  1. 假如redolog写入了，处于prepare状况，binlog还没写入，那么宕机重启后，redolog中的这个业务就直接回滚了。
  2. 假如redolog写入了，binlog也写入了，但redolog还没有更新为commit状况，那么宕机重启今后，mysql会去查看对应业务在binlog中是否完好。假如是，就提交业务；假如不是，就回滚业务。 (redolog处于prepare状况，binlog完好启动时就提交业务，为啥要这么设计? 主要是由于binlog写入了，那么就会被从库或者用这个binlog康复出来的库运用，为了数据一致性就选用了这个策略) redo log和binlog是经过xid这个字段关联起来的。