mysql查询过程

客官°小女子只卖身不卖艺 2023-07-24 08:38 138阅读 0赞

**1、mysql基本架构以及查询流程**

*  ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70][]
 *  MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。
 *  只要是你之前执行过的语句，都会在内存里面用key-value形式存储着。查询的时候就会拿着语句先去缓存中查询，如果能够命中就返回缓存的value，如果不命中就执行后面的阶段。
 *  **只要对表有任何的更新，这个表的所有查询缓存就会全部被清空**
 *  缓存在MySQL8.0之后就**取消**了。
 *  在缓存没有命中的情况下，就开始执行语句了，你写的语句有没有语法错误，这是接下来MySQL比较关心的点。
 *  会先做**词法分析**，你的语句有这么多单词、空格，MySQL就需要识别每个字符串所代表的是什么，是关键字，还是表名，还是列名等等。然后就开始**语法分析**，根据词法分析的结果，语法分析会判断你sql的对错，错了会提醒你的，并且会提示你哪里错了。
 *  之后就是**优化器，**因为我们建立表可能会建立很多索引，优化有一步就是要确认使用哪个索引，比如使用你的主键索引，联合索引还是什么索引更好。还有就是对执行顺序进行优化，条件那么多，先查哪个表，还是先关联，会出现很多方案，最后由优化器决定选用哪种方案。
 *  最后就是执行了，执行就交给执行器去做。
 *  [参考文章][Link 1]

2、**Mysql数据库都有哪些日志呢？分别什么作用？**

*  一般常见的有下面几种
 *  binlog日志：主要是恢复数据，主从复制
 *  redo log日志：保证事物中的持久化操作
 *  undo log日志：回滚和多版本控制(MVCC)

**3、binlog 介绍：**

*  `binlog`记录了数据库表结构和表数据变更，比如`update/delete/insert/truncate/create`。它不会记录`select`
 *  主要有两个作用：**复制和恢复数据**
 *  MySQL在公司使用的时候往往都是**一主多从**结构的，从服务器需要与主服务器的数据保持一致，这就是通过`binlog`来实现的
 *  数据库的数据被干掉了，我们可以通过`binlog`来对数据进行恢复。
 *  主从复制原理![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3phaV94aWE_size_16_color_FFFFFF_t_70]

**4、redo log 介绍：**

*  假设我们有一条sql语句：update user\_table set name='java3y' where id = '3'
 *  MySQL执行这条SQL语句，肯定是先把`id=3`的这条记录查出来，然后将`name`字段给改掉。
 *  实际上Mysql的基本存储结构是**页**(记录都存在页里边)，所以MySQL是先把这条记录所在的**页**找到，然后把该页加载到内存中，将对应记录进行修改。
 *  现在就可能存在一个问题：**如果在内存中把数据改了，还没来得及落磁盘，而此时的数据库挂了怎么办**？显然这次更改就丢了。
 *  如果每个请求都需要将数据**立马**落磁盘之后，那速度会很慢，MySQL可能也顶不住。所以MySQL是怎么做的呢？
 *  MySQL引入了`redo log`，内存写完了，会先写到buffer中，再真正落到磁盘中的`redo log`，这份`redo log`记载着这次**在某个页上做了什么修改**。

![format_png][]

*  写`redo log`也是需要写磁盘的，但它的好处就是`顺序IO`（我们都知道顺序IO比随机IO快非常多）。
 *  所以，`redo log`的存在为了：当我们修改的时候，写完内存了，但数据还没真正写到磁盘的时候。此时我们的数据库挂了，我们可以根据`redo log`来对数据进行恢复。因为`redo log`是顺序IO，所以**写入的速度很快**，并且`redo log`记载的是物理变化（xxxx页做了xxx修改），文件的体积很小，**恢复速度很快**。

**5、binlog和redo log区别**

*  看到这里，你可能会想：`binlog`和`redo log` 这俩也太像了吧，都是用作”恢复“的。其实他俩除了"恢复"这块是相似的，很多都不一样
 *  `binlog`记载的是`update/delete/insert`这样的SQL语句，而`redo log`记载的是物理修改的内容（xxxx页修改了xxx）。
 *  所以在搜索资料的时候会有这样的说法：`redo log` 记录的是数据的**物理变化**，`binlog` 记录的是数据的**逻辑变化**
 *  `redo log`的作用是为**持久化**而生的。写完内存，如果数据库挂了，那我们可以通过`redo log`来恢复内存还没来得及刷到磁盘的数据，将`redo log`加载到内存里边，那内存就能恢复到挂掉之前的数据了。
 *  `binlog`的作用是复制和恢复而生的。
    
     *  主从服务器需要保持数据的一致性，通过`binlog`来同步数据
     *  如果整个数据库的数据都被删除了，`binlog`存储着所有的数据变更情况，那么可以通过`binlog`来对数据进行恢复。
 *  又看到这里，你会想：”如果整个数据库的数据都被删除了，那我可以用`redo log`的记录来恢复吗？“**不能**
 *  因为功能的不同，`redo log` 存储的是物理数据的变更，如果我们内存的数据已经刷到了磁盘了，那`redo log`的数据就无效了。所以`redo log`不会存储着**历史**所有数据的变更，**文件的内容会被覆盖的**。
 *  `redo log`是MySQL的InnoDB引擎所产生的，`binlog`无论MySQL用什么引擎，都会有的。
 *  `redo log`**事务开始**的时候，就开始记录每次的变更信息，而`binlog`是在**事务提交**的时候才记录。
    
     *  如果写`redo log`失败了，那我们就认为这次事务有问题，回滚，不再写`binlog`
     *  如果写`redo log`成功了，写`binlog`，写`binlog`写一半了，但失败了怎么办？我们还是会对这次的**事务回滚**，将无效的`binlog`给删除（因为`binlog`会影响从库的数据，所以需要做删除操作）
     *  如果写`redo log`和`binlog`都成功了，那这次算是事务才会真正成功。
     *  简单来说：MySQL需要保证`redo log`和`binlog`的**数据是一致**的，如果不一致，那就乱套了。
     *  MySQL通过**两阶段提交**来保证`redo log`和`binlog`的数据是一致的。

6、**undo log 介绍：**

*  `undo log`主要有两个作用：回滚和多版本控制(MVCC)
 *  在数据修改的时候，不仅记录了`redo log`，还记录`undo log`，如果因为某些原因导致事务失败或回滚了，可以用`undo log`进行回滚
 *  `undo log`主要存储的也是逻辑日志，比如我们要`insert`一条数据了，那`undo log`会记录的一条对应的`delete`日志。我们要`update`一条记录时，它会记录一条对应**相反**的update记录。
 *  这也应该容易理解，毕竟回滚嘛，跟需要修改的操作相反就好，这样就能达到回滚的目的。因为支持回滚操作，所以我们就能保证：“**一个事务包含多个操作，这些操作要么全部执行，要么全都不执行**”
 *  因为`undo log`存储着修改之前的数据，相当于一个**前版本**，MVCC实现的是读写不阻塞，读的时候只要返回前一个版本的数据就行了。
 *  [参考文章][Link 2]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQ1NzEz_size_16_color_FFFFFF_t_70]: /images/20230528/da76a561db0b44f795ab97d486589435.png
[Link 1]: https://mp.weixin.qq.com/s/NDL1Q6nqdPq5oMBWSpq4ug
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3phaV94aWE_size_16_color_FFFFFF_t_70]: /images/20230528/09b716095d614a3aac261a0f57605546.png
[format_png]: /images/20230528/f4d71733f64e42a194c5cde6ed12f977.png
[Link 2]: https://mp.weixin.qq.com/s/Lx4TNPLQzYaknR7D3gmOmQ