mySQL实战笔记

001 基础架构,一条sql语句是如何执行的

连接器,查询缓存

首先,在一个客户端中,先进性mysql数据库的连接,在连接的时候会进行权限的判断,如果有权限,可以进入,如果没有权限或者密码错误,就会提示相关的信息,并且执行操作,如果市查询的任务,首先会在缓存中查询,连接分为长连接和短链接,长连接就是在谅解之后会一直执行操作,短链接就是连接之后指挥执行几次操作,就会自动断开,如果市mysql5.57版本之后,会进行连接的自动断开,而在操作过程中的查询会以key-value的形式存储在缓存中,如果遇相同的key(查询语句),就会直接调用缓存,如果不在,就会按照分析器,优化器,执行器的步骤进行操作.
这一步骤很像之前操作过的一个项目,先存储在redis中,如果redis中没有的化在取执行mysql,方便增加操作速度,不过mysql在5.57版本之后,就会自动断开长连接,而不用自己执行断开操作,这样子的化会减少mysql执行内存的占用.
在mysql8.0版本之后,查询缓存的功能消失,应为不实用,我个人感觉应该是有redis进行专业化的操作,导致mysql内部的一个缓存失去了实际的效果.

分析器

在分析器中,会进行语法的分析,判断语法是否合理,是否正确,同时,会根据表中的内容进行简单的判断.会更具关键字如select和表T进行判断分析,如果不能满足mysql的要求,就会返回

You have an error in your syntax

的提醒,比如你的select语句少一个t

 >mysql selec * from T where ID = 1;
ERROR 1064(42000): You have an error in your SQL syntax;
 

优化器

如过使用的表中又多个索引的时候,就会用到优化器,决定使用哪一个索引,或者多个表相关联的时候join,决定表的优先顺序
最终的目的是为了尽可能去提高查询的效率

执行器

确定所有顺去如何取查询之后,就会有执行器最终去操作,同时在这个阶段也会取判断一个权限问题,如果没有权限,就不会进入相关的信息内.,如果权限,就会打开表,髯后取执行.

02日志系统:一条sql语句是如何更新的

一个语句的执行是通过分析器,优化器,执行器,等模块的操作,然后进入存储引擎 .
更新流程设计两个重要的模块,redolog(重做日志)和binlog(归档日志)

redolog(重要的日志模块)

粉板和账本结合的操作就是mysql终的WAL技术Write Ahead Logging: 先写日志然后执行操作.
用户首先将查询信息输入mysql,mysql会先将更新信息计入redolog,然后跟新内存,更新操作完成,
InnoDB的redolog固定大小分位4个小组,每个小组1GB,成一个环状,从头开始写,写到尾之后在一边擦除执行存储一边进行写入操作.如下图所示

write pos是当前写入位置,check point是当前擦除位置,擦除前要吧数据进行存储操作.
write pos和check point之间的空白部分表示可以写入的位置,如果追上的话,就需要停止写入,开始执行擦除操作.有了redolog,就可以保证即使发生异常重启,也不会丢失数据,这个能力叫做crash-safe

binlog(重要的日志文件)

mysql有两个模块server还有一个就是引擎模块,负责存储相关的事宜,redolog是InnoDB引擎的特有日志,而server也有一个日志,binlog,
最开始mysql并没有InnoDB引擎,而是自身的MySAM引擎,但是MySAM没有crash-safe功能binlog日志只能用于归档,但是只依靠binlog是无法实现cresh-sage功能,所以只能搭配其他公司的InnoDB以插件形式使用,也就是redolog进行crash-sage.功能

redolog和binlog的不同点:
1.redolog是InnoDB引擎特有,而binlog是mysql终server中自带的.
2.redolog是物理日志,记录具体修改内容操作,而binlog是逻辑日志,记录操作完成的效果.
3.redolog是循环写,而binlog是追加写.

执行简单的update操作
根据关键字进行分析,优化,然后执行,在执行的过程中,首先引擎接口会将数据写入,将更新记录写入内存中,同时将操作记录写入redolog(处于prepare状态),告知执行器完成操作,随时可以提交事务,
执行器生成写入binlog操作,binlog写入磁盘
执行器调用的引擎提交事务接口,把redolog改成commit状态,更新完成.

这里redolog分为了两种状态,prepare和commit状态

redolog两阶段提交?

保证操作前后的日志保持逻辑一致

先写redolog,后写binlog

如果不分为两阶段,就会遇到一种状况,当redolog完成操作,后执行binlog的时候出现错误导致binlog记录未生成,这个时候通过redolog备份到之前的状态,回应魏binlog中未记录的部分和redolog中的值不同,库中的值就会与原库值不同.

先写binlog,后写redolog

binlog中写完之后crash-sage,但是redolog中没有记录,那么这个事务就会无效,根据binlog恢复后的库就会多一个事务出来,与原库不同.

总结

可以看出,如果不使用分段提交,恢复后的数据就有可能与源库不同.

这种情况会在扩建数据库的时候和备份数据库的时候也会用到.

这里拷贝一个用户的思路.更加形象一些.