mysql-学习-sql语句执行过程_sql语句执行顺序哪部分在磁盘哪部分在内存-CSDN博客

本文链接：https://blog.csdn.net/qq_30184197/article/details/105765749

Mysql组成部分

在这里插入图片描述
1、Server层

连接器
查询缓存
分析器
优化器
执行器
等

2、存储引擎层
负责数据的存储和提取，其架构模式是插件式的，支持InnoDB、MyISAM、Memory等

连接器

连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令一般是：

mysql -h $i p - P$ port -u$user -p

查询缓存

MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句，之前执行过的语句及期结果会以key-value的形式，被直接缓存在内在中，如果你的查询能够直接在这个缓存中找到key，那么value就会被直接返回客户端

查询缓存往往弊大于利，因为查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用，就被一个更新清空了，对于更新压力大的数据库来说，查询缓存的命中率会非常低，一般会在静态表上创建查询缓存。要以通过将query_cache_type 设置成 DEMAND 这样就不会使用查询缓存。MySQL 8.0 版本直接将查询缓存的整块功能删掉了。

分析器

先经过词法分析器，MySQL从你输入的 select 这个关键字识别出来，这是一个查询语句，它也要把字符串 T 识别成表名 T 把字符串 ID 识别成列ID

做完关键字识别后，就到”语法分析“ ，根据词法分析的结果，语法分析器会根据语法规则，判断你输入的SQL语句是否满足MySQL语法，如果你的语句不能，就会收到“You have an error in your SQL syntax”的错误提醒

优化器

优化器是表里面有多个索引的时候，决定使用哪个索引，或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序

执行器

对于执行语句：select * from T where ID=10；

开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误，如果有权限，就打开表继续执行。

调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是则跳过，如果是则将这行存在结果集中；
调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

重要的日志

redo log （InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe）
binlog （归档日志）

两者不同点

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

执行过程

update T set c=c+1 where ID=2;
在这里插入图片描述

执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

隔离级别

读未提交，一个事务还没提交时，它做的变更就能被别的事务看到。
读提交，一个事务提交之后，它做的变更才会被其他事务看到。
可重复读，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

举例：

若隔离级别是“读未提交”，则 V1 的值就是 2。这时候事务 B 虽然还没有提交，但是结果已经被 A 看到了。因此，V2、V3 也都是 2。
若隔离级别是“读提交”，则 V1 是 1，V2 的值是 2。事务 B 的更新在提交后才能被 A 看到。所以， V3 的值也是 2。
若隔离级别是“可重复读”，则 V1、V2 是 1，V3 是 2。之所以 V2 还是 1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
若隔离级别是“串行化”，则在事务 B 执行“将 1 改成 2”的时候，会被锁住。直到事务 A 提交后，事务 B 才可以继续执行。所以从 A 的角度看， V1、V2 值是 1，V3 的值是 2。

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。