Day01--查询语句执行流程
mysql 基础架构：
MySQL 5.5.5 版本开始InnoDB成为了默认存储引擎
连接器：
链接器超时断开参数 wait_timeout 默认 8小时
缓存
mysql 缓存提供按需使用的方式 将参数 query_cache_type 设置成 DEMAND，这样对于默认的 SQL 语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用 SQL_CACHE 显式指定
MySQL 8.0 版本直接将查询缓存的整块功能删掉了
mysql> select SQL_CACHE * from T where ID=10；
分析器：
分析器先会做“词法分析”。再做“语法分析”
优化器：
优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。
执行器：
首先判读用户对表有没有查询权限。如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。
数据库的慢查询日志中看到一个 rows_examined 的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的
Day02--更新语句执行流程
更新比查询多涉及两个日志模块 redo log 和 binlog
mysql> update T set c=c+1 where ID=2;
redo log
redo log 属于innodb 独有日志。
如图 InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写。
write pos 是当前记录的位置 heckpoint 是当前要擦除的位置。中间绿色部分为剩余空间。
有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe
binlog
binlog 是server 层的日志
这两种日志有以下三点不同。
redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
这个 update 语句的执行流程图，图中浅色框表示是在 InnoDB 内部执行的，深色框表示是在执行器中执行的。
最后三步将 redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶段提交"
好处：为了让两份日志之间的逻辑一致
文章来源：极客时间 丁奇--MYSQL 实战 45讲
