Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > update语句执行原理

详解一条update语句是怎样执行原理解析

作者：田埂

这篇文章主要为大家介绍了详解一条update语句是怎样执行原理解析，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪

前期准备

上一篇文章说完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层中的组件介绍

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

查询缓存✨： MySQL在得到一个执行请求后，会首先去 查询缓存 中查找，是否执行过这条SQL语句，之前执行过得语句以及结果会以 key-value对的形式，放在内存中。key是查询语句，value是查询的结果。如果通过key能够查找到这条SQL语句，直接返回SQL的执行结果。若不存在缓存中，就会继续后面的执行阶段。执行完成后，执行结果就会被放入查询缓存中。优点是效率高。但是查询缓存不建议使用， 因为在MySQL中对某张表进行了更新操作，那么所有的查询缓存就会失效，对于更新频繁的数据库来说，查询缓存的命中率很低。需要注意：在MySQL8.0版本，查询缓存功能就删除了，不存在查询缓存的功能了

分析器✨: 分为词法分析和语法分析

了解完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(重做日志)

听完上面对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和bin log的区别📍:

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突然宕机，会发生什么情况?

以上就是详解一条update语句是怎样执行原理解析的详细内容，更多关于update语句执行原理的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:
阅读全文