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，与原库的值不同。