【MySQL】SQL语句执行流程

一：查询语句的执行流程：

select * from user where id=1;

1、连接器：

mysql是BS架构，连接器负责跟客户端建立连接、获取权限、维持和管理连接。在完成经典的 TCP 握手后，连接器先通过一张视图：

use mysql
Databases changed
SELECT host,user,password from  user

验证账户，密码。通过后验证权限（权限验证通过之后成功建立连接，即使对这个用户的权限做了修改，也不会影响已经存在连接的权限。）

2、查询缓存：

之前执行过的语句及其结果被直接缓存在内存中（以 key-value 的形式，key为sql,value为记录）。MySQL 拿到一个查询请求后，先查询缓存，若存在则直接返回。

（只要有对一个表的更新，这个表上所有的查询缓存都会被清空。所以命中率低。mysql8.8已砍掉缓存功能）

3、分析器

语法、词法分析。校验sql语句是否有误。

4、优化器

优化器是在表里面有多个索引的时候，决定使用哪个索引；

在一个语句有多表关联（join）的时候，决定各个表的连接顺序。

5、执行器

执行器就会根据表的引擎定义，调用引擎提供的接口。

select * from user where id=1;

若id字段没有索引，则执行器

从表的第一行开始扫描，满足id=1的行，存在结果集中；不是则跳过。扫描完全表，返回结果集。

二：更新语句执行流程

执行更新语句时，和这个表有关的缓存都会失效。更新语句前需要先找到语句，所以上面的查询流程一样会走一遍。

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

涉及到的redolog和binlog日志，需要结合下一篇【MySQL日志】理解

两阶段提交如何保证数据一致性呢：
1、redolog prepare阶段  2、写binlog 3、redo log的commit阶段
若在2之前宕机
重启恢复：发现redolog不是commit状态则进行回滚操作。且备份恢复，没有binlog，是一致的。
若在2之后宕机
重启恢复：发现redolog不是commit状态，但满足prepare和binlog完整，所以重启后会自动commit。且备份恢复备份：有binlog是一致

反证法：如果不采用两阶段提交：

先写 redo log 后写 binlog。假设在 redo log 刚写完，binlog 还没有写完的时候，MySQL 进程异常重启。
由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。
但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。
因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。
然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，
这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。

先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，
所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。
所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。