Mysql 执行一条语句的过程
Mysql的逻辑架构Mysql的逻辑架构如下所示，整体分为两部分，Server层和存储引擎层。与存储引擎无关的操作都是在Server层完成的，存储引擎层负责数据的存取。https://img-blog.csdnimg.cn/7076d97579234deba3dcbd6534415417.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBATWF5IEhhY2tlcg==,size_20,color_FFFFFF,t_70,g_se,x_16下面将会按照上图的过程分别介绍每一步的作用，这里以查询一条记录为例。连接器这一步主要是管理连接和权限验证。
负责管理客户端的连接，比如mysql -u root -p，就是客户端与连接器之间完成的，连接分为长连接和短连接，建议使用长连接，因为建立连接是相对复杂的一个过程。但是长连接也有优化的空间，即长连接过多，随着执行大的查询操作，会占用较多的内存。
建立连接完成之后，连接器会判断该用户的权限，之后用户的操作都会基于权限来判定是否允许。
分析器这一步主要是词法分析和语法分析。
词法分析主要是判定用户想做什么，比如select 就是想要查询。
语法分析主要是判定用户输入的SQL是否符合Mysql的语法。
优化器经过分析器，Mysql已经知道用户想要干什么了，但是对于相同的一条SQL语句，对于Mysql具体实施的时候，可能有多种方法去实现，效率也就不一样。
在优化器这一步，mysql需要判定怎么样执行才是最优的效率。
执行器这一步主要是操作引擎和返回结果。通过操作存储引擎层来遍历一张数据表，去寻找符合条件的数据，并且返回给客户端。
Mysql执行一条更新语句的过程与一条SQL查询语句相同的是，在Mysql中同样要经过连接器、分析器、优化器、执行器，也要用到存储引擎来进行数据的存取。https://img-blog.csdnimg.cn/7076d97579234deba3dcbd6534415417.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBATWF5IEhhY2tlcg==,size_20,color_FFFFFF,t_70,g_se,x_16不同的是，更新语句需要涉及到两个重要的日志模块，redo log和binlog
redo log一家饭店生意红火，但作为一家饭店来说，免不了每天都有赊账和来还账的。
如果赊账和还账的人不多还好，老板可以直接用一块粉板来记录，如果人多，粉板根本写不下一个月的赊账记录。
所以老板想到可以把所有的赊账记录写到账本上，而粉板上写的都是短时间的，等下班了之后，拿粉板上的和账本进行对账。
在这个例子中，粉板就是redo log，账本就是mysql中的记录，我们用还账类比一下mysql的更新过程，如果每次有人更新，我们都去mysql中找到这条记录，效率很低，所以mysql的思路和这个老板一致，更新操作先放到redo log中，过一段时间再慢慢消化。
这种思路叫WAL技术，即Write Ahead Logging技术，先写日志，再写磁盘。
需要注意的是，粉板如果满了，老板还没下班，老板就必须停下来手中的活。mysql中的redo log总共可以记录4GB的操作https://img-blog.csdnimg.cn/834e1d99efad4c6a9858ab897d383d23.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBATWF5IEhhY2tlcg==,size_20,color_FFFFFF,t_70,g_se,x_16当write pos 追上check point，mysql这个老板就要去处理一下redo log了。
除此之外，有了redo log持久化，数据库即使异常重启也不会丢日志，这是crash safe机制，但仍需要注意的是，redo log是innodb存储引擎特有的。
bin logbinlog是Server层的日志，可以适用于所有存储引擎。
那既然有binlog了，前文为什么要搞一个innodb存储引擎专属的redo log呢？
因为mysql最开始没有innodb引擎，而是myisam引擎，使用的是binlog，但是binlog仅限于归档，没有crash safe机制，于是自己补充了一个redo log。
redo log是innodb存储引擎特有的，而binlog是server层特有的redo log存储的是物理日志，binlog是逻辑日志redo log像上面讲的那样，支持4GB大小，多了就得处理并且去覆盖，binlog日志当写满一个日志文件之后，会新建一个新的日志文件。下面以更新ID为2的一行数据为例：
图中浅色框表示是在 InnoDB 内部执行的，深色框表示是在执行器中执行的。https://img-blog.csdnimg.cn/c13b6ad9a5b64259889ff354d81be7c1.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBATWF5IEhhY2tlcg==,size_20,color_FFFFFF,t_70,g_se,x_16执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。执行器生成这个操作的 binlog，并把 binlog 写入磁盘。执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。————————————————版权声明：本文为CSDN博主「May Hacker」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/weixin_43889841/article/details/122706636
页:
[1]