mysql执行流程

发表于 | 分类于 | 阅读次数

　

mysql主要分为Server层和存储引擎层

Server层：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binglog日志模块。

存储引擎： 主要负责数据的存储和读取，采用可以替换的插件式架构，支持InnoDB、MyISAM、Memory等多个存储引擎，其中InnoDB引擎有自有的日志模块redolog 模块。

server层

连接器

主要负责用户登录数据库，进行用户的身份认证，包括校验账户密码，权限等操作，如果用户账户密码已通过，连接器会到权限表中查询该用户的所有权限，之后在这个连接里的权限逻辑判断都是会依赖此时读取到的权限数据，也就是说，后续只要这个连接不断开，即时管理员修改了该用户的权限，该用户也是不受影响的。

mysql中存在4个控制权限的表，分别为user表，db表，tables_priv表，columns_priv表**,mysql权限表的验证过程

  • user表 存放用户账户信息以及全局级别（所有数据库）权限，决定了来自哪些主机的哪些用户可以访问数据库实例
  • db表 存放数据库级别的权限，决定了来自哪些主机的哪些用户可以访问此数据库
  • tables_priv表存放表级别的权限，决定了来自哪些主机的哪些用户可以访问数据库的这个表
  • columns_priv表 存放列级别的权限，决定了来自哪些主机的哪些用户可以访问数据库表的这个字段
  • Procs_priv 存放存储过程和函数级别的权限

先从user表中的Host,User,Password这3个字段中判断连接的ip、用户名、密码是否存在，存在则通过验证。

通过身份认证后，进行权限分配，按照user，db，tables_priv，columns_priv的顺序进行验证。即先检查全局权限表user，如果user中对应的权限为Y，则此用户对所有数据库的权限都为Y，将不再检查db, tables_priv,columns_priv；如果为N，则到db表中检查此用户对应的具体数据库，并得到db中为Y的权限；如果db中为N，则检查tables_priv中此数据库对应的具体表，取得表中的权限Y，以此类推

查询缓存

mysql的缓存主要的作用是为了提升查询的效率，缓存以key和value的哈希表形式存储，key是具体的sql语句，value是结果的集合。如果无法命中缓存,就继续走到分析器的的一步,如果命中缓存就直接返回给客户端 。如果没有命中，就会执行后续的操作，完成后也会把结果缓存起来，方便下一次调用。当然在真正执行缓存查询的时候还是会校验用户的权限，是否有该表的查询条件。

Mysql 查询不建议使用缓存，之所以删除掉,是因为查询缓存的失效非常频繁,如果在一个写多读少的环境中,缓存会频繁的新增和失效。对于某些更新压力大的数据库来说，查询缓存的命中率会非常低,mysql为了维护缓存可能会出现一定的伸缩性的问题,目前在5.6的版本中已经默认关闭了，比较推荐的一种做法是将缓存放在客户端，性能大概会提升5倍左右

分析器

mysql 没有命中缓存，那么就会进入分析器

第一步，词法分析，一条SQL语句有多个字符串组成，首先要提取关键字，比如select，提出查询的表，提出字段名，提出查询条件等等。做完这些操作后，就会进入第二步。

第二步，语法分析，主要就是判断你输入的sql是否正确，是否符合mysql的语法。

完成这2步之后，mysql就准备开始执行了，但是如何执行，怎么执行是最好的结果呢？这个时候就需要优化器上场了。

优化器

优化器的作用就是它认为的最优的执行方案去执行（虽然有时候也不是最优），比如多个索引的时候该如何选择索引，多表查询的时候如何选择关联顺序等。

执行器

当选择了执行方案后，mysql就准备开始执行了，首先执行前会校验该用户有没有权限，如果没有权限，就会返回错误信息，如果有权限，此时会调用存储引擎的API，返回接口执行的结果。

执行过程

select不会记录到binlog中,只有update/delete/insert才会记录到binlog中。而update会采用两阶段提交的方式,记录都redolog中

查询

  • 先检查该语句是否有权限，如果没有权限，直接返回错误信息，如果有权限，在mysql8.0版本以前，会先查询缓存，以这条sql语句为key在内存中查询是否有结果，如果有直接缓存，如果没有，执行下一步。
  • 通过分析器进行词法分析，提取sql语句的关键元素，比如提取上面这个语句是查询select，提取需要查询的表名为tb_student,需要查询所有的列，查询条件是这个表的id=’1’。然后判断这个sql语句是否有语法错误，比如关键词是否正确等等，如果检查没问题就执行下一步。
  • 接下来就是优化器进行确定执行方案，上面的sql语句，可以有两种执行方案：
1
2
  a.先查询学生表中姓名为“张三”的学生，然后判断是否年龄是18。
  b.先找出学生中年龄18岁的学生，然后再查询姓名为“张三”的学生。
  • 那么优化器根据自己的优化算法进行选择执行效率最好的一个方案（优化器认为，有时候不一定最好）。那么确认了执行计划后就准备开始执行了。
  • 进行权限校验，如果没有权限就会返回错误信息，如果有权限就会调用数据库引擎接口，返回引擎的执行结果。

sql并不是按照我们的书写顺序来从前往后、左往右依次执行的,它是按照固定的顺序解析的,主要的作用就是从上一个阶段的执行返回结果来提供给下一阶段使用，sql在执行的过程中会有不同的临时中间表，一般是按照如下顺序

更新

其实，update语句的执行过程和select语句差不多，但是在update语句执行的过程中，MySQL新增加了两个重要的日志模块，他们分别是redo log(重做日志)和binlog（二进制日志、也可以称之为归档日志）。

  • 先查询到要修改的，如果有缓存，也是会用到缓存。
  • 进行更新操作，调用引擎API接口数据保存在内存中，同时将这个更新操作记录到redo log 里面。
  • redo log进入prepare状态，然后告诉执行器，执行完成了，随时可以提交
  • 执行器收到通知后记录binlog
  • 然后调用引擎接口，提交redo log 为提交状态
  • 执行器调用引擎的提交事务接口
  • 事务的两阶段提交：commit的prepare阶段：引擎把刚刚写入的redo log刷盘；
  • 事务的两阶段提交：commit的commit阶段：引擎binlog刷盘。

2PC即Innodb对于事务的两阶段提交机制。当MySQL开启binlog的时候，会存在一个内部XA的问题：事务在存储引擎层（redo）commit的顺序和在binlog中提交的顺序不一致的问题。如果不使用两阶段提交，那么数据库的状态有可能用它的日志恢复出来的库的状态不一致。

1、先写binlog再写redo，binlog完成之后，服务器crash了，binlog中id=1了，但是由于redo log没有写，在服务器恢复的时候，恢复出来的值是0，但是我们用binlog恢复出来的值将会变成1，二者产生了不一致的现象；

2、先写redo log，再写binlog，假设redo log写完之后MySQL崩溃重启，仍然能够把数据恢复回来，所以恢复后这一行c的值是1，但是由于没有写入binlog， 那么使用binlog恢复出来的值就是0，和实际结果不符。

一般情况下，当我们出现误操作时，大概率会使用全量备份+binlog的方式恢复数据，而如果此时使用binlog恢复出来的数据有误，那无疑会对业务产生影响。

有了”两阶段提交”，我们把整个过程拆分为三个部分：

1、prepare阶段

2、 写binlog

3 、commit

当实例宕机后，恢复的过程如下：

情况1：当在2之前崩溃时

重启恢复：后发现没有commit，回滚。

备份恢复：没有binlog 。

重启恢复和备份恢复一致

情况2：当在3之前崩溃

重启恢复：虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。

备份恢复：有binlog.

重启恢复和备份恢复一致

redo log 写入机制

Redo Log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。

redo log 不是记录数据页更新之后的状态，而是记录这个页做了什么改动。

redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么日志总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写

  • write pos是当前记录的位置
  • checkpoint是当前要擦除的位置

checkpoint 是当前要擦除的位置，擦除记录前需要先把对应的数据落盘（更新内存页，等待刷脏页）。write pos 到 checkpoint 之间的部分可以用来记录新的操作，如果 write pos 和 checkpoint 相遇，说明 redolog 已满，这个时候数据库停止进行数据库更新语句的执行，转而进行 redo log 日志同步到磁盘中。checkpoint 到 write pos 之间的部分等待落盘（先更新内存页，然后等待刷脏页）。

redo log 与 binlog 的区别

  • redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
  • redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑
  • redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。追加写是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

redo log与binlog区别

  redo log binlog
文件大小 redo log的大小是固定的。 binlog可通过配置参数max_binlog_size设置每个binlog文件的大小。
实现方式 redo log是InnoDB引擎层实现的，并不是所有引擎都有。 binlog是Server层实现的，所有引擎都可以使用 binlog日志
记录方式 redo log 采用循环写的方式记录，当写到结尾时，会回到开头循环写日志。 binlog 通过追加的方式记录，当文件大小大于给定值后，后续的日志会记录到新的文件上
适用场景 redo log适用于崩溃恢复(crash-safe) binlog适用于主从复制和数据恢复

redo binlog undo log 区别