做公司网站需要什么:6步带你看懂MySQL 全体架构
本文摘要: 文末收取【医疗行业数据盘点陈述】MySQL 在全体架构上分为 Server 层和存储引擎层。其间 Server 层,包括连接器、查询缓存、分析器、优化器、执行器等,存储过程、触发器、视图和内置函数都在这层完成。数据引擎层负责数据的存储

文末收取【医疗行业数据盘点陈述】

MySQL 在全体架构上分为 Server 层和存储引擎层。其间 Server 层,包括连接器、查询缓存、分析器、优化器、执行器等,存储过程、触发器、视图和内置函数都在这层完成。数据引擎层负责数据的存储和提取,如 InnoDB、MyISAM、Memory 等引擎。在客户端连接到 Server 层后,Server 会调用数据引擎提供的接口,进行数据的变更。

连接器

负责和客户端建立连接,获取用户权限以及维持和管理连接。

通过show processlist来查询连接的状态。在用户建立连接后,即便管理员改变连接用户的权限,也不会影响到已连接的用户。默许连接时长为 8 小时,超过期间后将会被断开。

简略说下长连接:

1. 优势:在连接时间内,客户端一直使用同一连接,防止屡次连接的资源耗费。

2. 劣势:在MySQL执行时,使用的内存被连接对象管理,因为长时间没有被开释,会导致体系内存溢出,被体系kill. 所以需要守时断开长连接,或执行大查询后,断开连接。MySQL 5.7 后,可以通过mysql_rest_connection初始化连接资源,不需要重连或者做权限验证。

查询缓存

当承受到查询请求时,会现在查询缓存中查询(key/value保存),是否执行过。没有的话,再走正常的执行流程。

但在实践状况下,查询缓存一般没有必要设置。因为在查询触及到的表被更新时,缓存就会被清空。所以适用于静态表。在MySQL8.0后,查询缓存被废弃。

分析器

1. 词法分析:如辨认select,表名,列名,判断其是否存在等。

2. 语法分析:判断语句是否契合MySQL语法。

优化器

确定索引的使用,join表的连接顺序等,选择最优化的方案。

执行器

在详细执行语句前,会先进行权限的查看,通往后使用数据引擎提供的接口,进行查询。假如设置了慢查询,会在对应日志中看到rows_examined来表明扫描的行数。在一些场景下(索引),执行器调用一次,但在数据引擎中扫描了多行,所以引擎扫描的行数和rows_examined其实不完全相同。

不预先查看权限的原因:如像触发器等状况,需要在执行器阶段才干确定权限,在优化器阶段无法验证。

MySQL 日志模块

如前面所说,MySQL全体分为Server层和数据引擎层,而每层也对应了自己的日志文件。假如选用的是InnoDB引擎,对应的是redo log文件。Server层则对应了binlog文件。至于为何存在了两种日志体系,我们往下看。

1. redo log


redo log是InnoDB特有日志,为何要引入redo log呢,想象这样一个场景,MySQL为了保证耐久性是需要把数据写入磁盘文件的。我们知道,在写入磁盘时,会进行文件的 IO,查找操作,假如每次更新操作都这样的话,全体的功率就会特别低,底子没法使用。

既然直接写入磁盘不行,解决方法就是先写进内存,在体系闲暇时再更新到磁盘就能够了。但光更新内存不行,假定体系呈现异常宕机和重启,内存中没有被写入磁盘的数据就会被丢掉,数据的一致性就呈现问题了。

这时候redo log就发挥了作用,在更新操作发生时,InnoDb会先写入redo log日志(记载了数据发生了怎样的改变),然后更新内存,终究在适当的时间再写入磁盘。先写日志,在写磁盘的操作,就是常说到的WAL(Write-Ahead- Logging)技能。

redo log的呈现,除了在功率上有了很大的改善,还保证了MySQL具有了crash-safe的能力,在发生异常状况下,不会丢掉数据。

在详细完成上redo log的巨细是固定的,可配置一组为 4 个文件,每一个文件1GB,更新时对四个文件进行循环写入。

write pos记载其时写入的方位,写完就后移,当第写入第4个文件的末尾时,从第0号方位从头写入。

check point表明其时可以擦除的方位,当数据更新到磁盘时,check point就向后移动。

write pos和check point之间的方位,就是可以记载更新操作的空间。当write pos追上check point ,不在能执行新的操作,先让check point去写入一些数据。

可以将innodb_flush_log_at_trx_commit设置成1,开启redo log耐久化的能力。

2. binlog


binlog则是Server层的日志,主要用于归档,在备份,主备同步,恢复数据时发挥作用,常见的日志格局有row, mixed, statement三种。

可以通过sync_binlog=1开启binlog写入磁盘。

这里对binlog和 redo进行下区分:

  • 所有者不同:binlog是 Server层,所有引擎都可以使用。redo log是 InnoDB独有的。

  • 类型不同:binlog是逻辑日志,记载的是语句的原始逻辑(比 statement)。redo log是物理日志,记载某个数据页被做了怎样的修正。

  • 数据写入的方式不同:binog日志会一直追加,而redo log是循环写入。

  • 功用不同:binlog用于归档,而redo log用于保证crash-safe。

3. 两阶段提交

一条更新语句,在InnoDB引擎下的更新过程如下。在更新内存后,将写入redolog和写入 binlog放在一同成为一个事务终究一同写入redo log和 binlog的过程就是常说的两阶段提交。用于保证当有意外状况发生时,数据的一致性。

这里假设下,假如不选用两阶段提交会发生什么?

  • 先写redo log后写binlog假设在写入redo log后,MySQL发生异常重启,此时binlog没有写入。在重启后,因为redolog现已写入,此时数据库的内容是没有问题的。但此时,假如想要拿binlog进行备份或恢复,发现会少了终究一条的更新逻辑,导致数据不一致。

  • 先写binlog和redo log. binlog写入后,MySQL异常重启,redo log没有写入。此时重启后,发现redo log没有成功写入,认为这个事务无效,而此时binlog却多了一条更新语句,拿去恢复后天然数据也是不一致的。

再分析下两阶段提交的过程:

  • 在写redo log prepare阶段奔溃,重启后,发现redo log没写入,回滚此次事务。

  • 假如在写binlog时奔溃,重启后,发现binlog未被写入,回滚操作

  • 假如在写入redo log和binlog后溃散,重启后,发现没提交,则进行commit。

总结

在文章开始部分,说明了MySQL的全体架构分为Server层和引擎层,并简要说明了一条语句的执行过程。接着MySQL在5.5后选用InnoDB作为默许的引擎,就是因为比原生的MyISAM多了事务以及crash-safe的能力。

而crash-safe就是由redo log完成的。与redo log类似的日志文件还有binlog,是Server引擎的日志,用于归档和备份数据。

终究提到了,为了保证数据的一致性,将redo log和binlog放入相同的事务中,也就是常提到的两阶段提交操作。

End.

作者:以终为始

来历:博客园

本文为转载分享,如侵权请联络后台删除

长按下方海报收取【医疗行业数据盘点陈述】

MySQL查询性能优化详解 | 引荐保藏

9个Excel技巧,让你的工作功率飞升!

引爆用户增加必备的5大体素!


【免责声明】本文仅代表作者或发布者个人观念,不代表(www.lmnkf.cn)及其所属公司官方发声,对文章观念有疑义请先联络作者或发布者自己修正,若内容触及侵权或违法信息,请先联络发布者或作者删除,若需我们协助请联络平台管理员,Emailcxb5918(本平台不支撑其他投诉反馈渠道,谢谢合作)。若需要学习以上相关常识请到巨推学院观看视频教程,网站地址www.tsllg.cn。

相关内容