共计 1896 个字符，预计需要花费 5 分钟才能阅读完成。
Mysql 的根本架构图
mysql8 之后不存在查问缓存了
1、连接器
▪ 连接器负责跟客户端建设连贯，获取权限、维持和治理连贯
– 用户名明码验证
– 查问权限信息，调配对应的权限
– 能够应用 show processlist 查看当初的连贯
– 如果太长时间没有动静，就会主动断开，通过 wait_timeout 管制，默认 8 小时
▪ 连贯能够分为两类：
– 长连贯：举荐应用，然而要周期性的断开长连贯
– 短链接：
查问缓存
▪ 当执行查问语句的时候，会先去查问缓存中查看后果，之前执行过的 sql 语句及其后果可能以 key-value 的模式存储在缓存中，如果能找到则间接返回，如果找不到，就继续执行后续的阶段。
▪ 然而，不举荐应用查问缓存：
– 1、查问缓存的生效比拟频繁，只有表更新，缓存就会清空
– 2、缓存对应新更新的数据命中率比拟低
2、分析器
▪ 词法剖析：Mysql 须要把输出的字符串进行辨认每个局部代表什么意思
– 把字符串 T 辨认成 表名 T
– 把字符串 ID 辨认成 列 ID
▪ 语法分析：
▪ 依据语法规定判断这个 sql 语句是否满足 mysql 的语法，如果不合乎就会报错“You have an error in your SQL synta”
3、优化器
▪ 在具体执行 SQL 语句之前，要先通过优化器的解决
– 当表中有多个索引的时候，决定用哪个索引
– 当 sql 语句须要做多表关联的时候，决定表的连贯程序等等
▪ 不同的执行形式对 SQL 语句的执行效率影响很大
– RBO: 基于规定的优化
– CBO: 基于老本的优化
4、Redo 日志—innodb 存储引擎的日志文件
▪ 当产生数据批改的时候，innodb 引擎会先将记录写到 redo log 中，并更新内存，此时更新就算是实现了，同时 innodb 引擎会在适合的机会将记录操作到磁盘中
▪ Redolog 是固定大小的，是循环写的过程
▪ 有了 redolog 之后，innodb 就能够保障即便数据库产生异样重启，之前的记录也不会失落，叫做 crash-safe
5、纳闷
6、Undo log
▪ Undo Log 是为了实现事务的原子性，在 MySQL 数据库 InnoDB 存储引擎中，还用 Undo Log 来实现多版本并发管制 (简称：MVCC)
▪ 在操作任何数据之前，首先将数据备份到一个中央（这个存储数据备份的中央称为 Undo Log）。而后进行数据的批改。如果呈现了谬误或者用户执行了 ROLLBACK 语句，零碎能够利用 Undo Log 中的备份将数据恢复到事务开始之前的状态
▪ 留神：undo log 是逻辑日志，能够了解为：
– 当 delete 一条记录时，undo log 中会记录一条对应的 insert 记录
– 当 insert 一条记录时，undo log 中会记录一条对应的 delete 记录
– 当 update 一条记录时，它记录一条对应相同的 update 记录
7、binlog—服务端的日志文件
▪ Binlog 是 server 层的日志，次要做 mysql 性能层面的事件
▪ 与 redo 日志的区别:
– 1、redo 是 innodb 独有的，binlog 是所有引擎都能够应用的
– 2、redo 是物理日志，记录的是在某个数据页上做了什么批改，binlog 是逻辑日志，记录的是这个语句的原始逻辑
– 3、redo 是循环写的，空间会用完，binlog 是能够追加写的，不会笼罩之前的日志信息
binlog
▪ Binlog 中会记录所有的逻辑，并且采纳追加写的形式
▪ 个别在企业中数据库会有备份零碎，能够定期执行备份，备份的周期能够本人设置
▪ 复原数据的过程：
– 1、找到最近一次的全量备份数据
– 2、从备份的工夫点开始，将备份的 binlog 取出来，重放到要复原的那个时刻
8、数据更新的流程
9、Redo log 的两阶段提交
▪ 先写 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，与原库的值不同。
