基本架构介绍
连接器：管理连接，权限验证
用户名密码的验证，查看权限信息，分配权限，可以使用show full processlist查看现在的连接
连接可以分为两种，长连接和短连接
查询缓存：
当执行查询语句时，会先去查询缓存中查看结果，之前执行过的sql语句，可能以key-value的形式存储缓存中，找到直接返回，找不到，继续执行后续操作
分析器：词法分析，语法分析
会按照规则进行分析，如果语法错误会直接返回，不会继续往下进行
优化器：执行计划、索引选择
再具体执行sql语句之前，要先经过优化器的处理，如当表中有多个索引的时候，决定用哪个索引
执行器：操作引擎、返回结果
访问存储引擎，返回获取数据并返回数据
mysql中三个日志文件
redo log
当发生数据修改的时，innodb引擎会先将记录写到redo log中，并更新内存，此时更新就算完成了，同是innodb引擎会在合适的时机将记录操作到磁盘中，redo log是固定大小的，是循环写的过程，就算数据库发生异常重启，数据也不会丢失，叫做crash-safe。
什么是crash-safe呢？
比如我们配置一组四个文件，每个文件 1 GB，那样 redo log 就可以存储 4GB 的数据
- redo log 一共有两个指针组成，分别是 write-pos 和 check-point
- write pos：记录当前写入的位置
- check point：检查点，记录有哪些数据更新到了数据文件
- 绿色位置就是redo log 空闲空间
当 write-pos 追上了 check-point 时，则需要阻塞更新操作，将操作更新到数据文件。
鸣谢: https://blog.csdn.net/u013546788/article/details/106346490
为了更好理解redo log的作用引入一则小故事，很形象
账本与记账板
假如您当了小超市老板，自然会有一个账本记录交易记录，但是可能还要一个赊账记录。因为村里有个姑娘叫小芳，长得美丽又善良。有时候会到你这里白嫖，额，不是，是赊账。你先把记录写在小粉板上，等夜深人静的时候就把粉板的数据同步到归档的账本中。当然粉板也有满的时候，所以当粉板满了就要对账写入账本中，
所以，如果有人要来赊账，或者还账的时候，通常有两种做法：
- 直接把账本翻出来，把这次的赊账加上去或者扣除。
- 先在粉板上记下这次的帐，等打烊后再把账本翻出来核算。
在生意忙的时候，我们肯定选择后者，因为前者操作太麻烦了。首先，你得找到这个人的赊账总额那条记录。你想想，密密麻麻几十页，掌柜要找到那个名字，可
能还得带上老花镜慢慢找，找到之后再拿出算盘计算，最后再将结果写回到账本上。这个时候小芳来赊账，等半天。以后还怎么约小芳到小树林呢？
在 MySQL 中也有这个问题，如果每一次操作都要写进磁盘，然后磁盘也要找到对应的记录，然后再更新。整个过程的 IO 成本，查询成本都很高，为了解决这个问题，MySQL的设计者就用了类似小超市老板粉板的思路来提升更新效率。
而粉板和账本配合的整个过程，其实就是 MySQL 里经常说到的 WAL 技术，WAL 的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。
小故事引用鸣谢：https://blog.csdn.net/qq_14855971/article/details/103636808
undo log
undolog是为了实现事务的原子性，在mysql数据库innodb存储引擎中，还用undolog实现多版本并发控制简称（mvcc），在操作更改任何数据之前，首先将数据备份到一个地方（这个地方叫做undolog）。然后进行数据的修改。如果出现了错误或者用户执行rollback语句，系统可以利用undo log中的备份将数据恢复到事务开始之前的状态。
注意：undo log 是逻辑日志，可以理解为：
- delete 一条记录 undolog中柜记录一条对应的insert记录
- insert 一条记录 undo log 中会记录一条delete记录
- update一条记录 undo log中记录一条相反的update记录
binlog
binlog是server层的日志，主要做mysql功能层面的事情，
- redo是innodb独有的 binlog是所有引擎都有的
- redo是物理日志记录的是某个数据页上做了什么修改，binlog是逻辑日志，记录的是这个语句的原始逻辑
- redo是循环写的，空间会用完，binlog是可以追加写的，不会覆盖之前的日志信息
一般binlog日志是用来做备份系统，可以定期执行备份
数据更新流程
注：深绿色是mysql server的工作，浅绿色是innodb引擎做的工作
数据更新的过程
（1）更新语句经过 解析，优化 生成执行计划，交由执行器调用存储引擎接口（注：执行器会多次调用存储引擎接口，并不是一次完成）
（2）查询旧值，先去内存缓冲区查看是否有数据，如果没有，从磁盘中加载到内存，并将旧值写入到 Undo log 日志中，用于回滚数据
（3）更新内存中的数据（注：磁盘仍为旧数据）
（4）将操作写入到Redo Log 中，此时处于prepare阶段
（5）Redo Log根据刷盘策略刷到磁盘
（6）准备提交事务，写入binlog 日志（注：binlog也有自己的刷盘策略）
（7）把本次更新对应的binlog文件名称和这次 更新的binlog日志在文件里的位置，都写入到redo log日志文件里去，之后在redo log日志文件里写入一个commit标 记。
（8）事务完成
其实到此数据更新就算完成了，当服务器空闲时，会将redo.log日志更新至表中
当使用过程中突然断电，redolog会将已经写入的数据按照处于prepare的数据先写入binlog再commit，最后写入数据库表中，保证数据不会丢失