Mysql分层架构

Mysql分层架构

  • 一、基础架构
    • 1.连接器
    • 2.查询缓存
    • 2.分析器
    • 3 优化器
    • 4 执行器
  • 二、redo log 和 bin log
    • 1.undo log 与 MVCC
    • 2、redo log 与 Buffer Pool
    • 1.bin log
  • 总结

一、基础架构

Mysql分层架构_第1张图片

1.连接器

1.会先连接到这个数据库上,这时候接待你的就是连接器。连接器负责跟客户端建立连接、获取权限、维持和管理连接

2.用户密码连接成功之后,会从权限表中拿出你的权限,后续操作权限都依赖于此时拿出的权限,这就意味着当链接完成之后即使有人修改了你的用户权限,也不会影响你先有的链接

3.长连接是指连接成功后,如果客户端持续有请求,则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连 全部使用长链接的时候,你会发现内存涨的非常快,因为mysql执行过程中的临时内存都是管理在链接对象里面的,这些资源在链接断开的时候才会释放,可能占用内存太大。

3,解决方案有两个 1.判断占用大内存的查询的时候断开链接,之后要查询再重新链接 2.果你用的是 MySQL 5.7 或更新版本,可以在每次执行一个比较大的操作后,通过执行 mysql_reset_connection 来重新初始化连接资

2.查询缓存

会以key,value形式缓存执行过的语句和执行结果,一旦有更新或者删除操作就会释放 可以设置query_cache_type 判断是否使用缓存。 8.0之后 不再使用缓存了

1、查询语句不一致。前后两条查询SQL必须完全一致。

2、查询语句中含有一些不确定的值时,则不会缓存。比如 now()、current_date()、curdate()、curtime()、rand()、uuid()等。

3、不使用任何表查询。如 select ‘A’;

4、查询 mysql、information_schema 或 performance_schema 数据库中的表时,不会走查询缓存。

5、在存储的函数,触发器或事件的主体内执行的查询。

6、如果表更改,则使用该表的所有高速缓存查询都变为无效并从缓存中删除,这包括使用 MERGE 映射到已更改表的表的查询。一个表可以被许多类型的语句改变,如 insert、update、delete、truncate rable、alter table、drop table、drop database。

2.分析器

分析语法,判断语法是否正确

3 优化器

决定使用哪个索引;或者在一个语句有多表关联(join)的时候,决定各个表的连接顺序

4 执行器

二、redo log 和 bin log

1.undo log 与 MVCC

undo log是 Innodb 引擎专属的日志,是记录每行数据事务执行前的数据。主要作用是用于实现MVCC版本控制,保证事务隔离级别的读已提交和读未提交级别。而 MVCC 相关的可以参考 https://www.cnblogs.com/mengxinJ/p/14053269.html#_label1_0_0

2、redo log 与 Buffer Pool

redo log存储的内容是对数据页的修改逻辑。

如果每一次的更新操作都需要写进磁盘,然后磁盘也要找到对应的那条记录,然后再更新,整个过程 IO 成本、查找成本都很高。为了解决这个问题,MySQL 的设计者就用了类似酒店掌柜粉板的思路来提升更新效率。而粉板和账本配合的整个过程,其实就是 MySQL 里经常说到的 WAL 技术,WAL 的全称是 Write-Ahead Logging,它的关键点就是先写日志,再写磁盘,也就是先写粉板,等不忙的时候再写账本
Mysql分层架构_第2张图片
write pos 表示当前正在记录的位置,会向后记录, checkpoint 表示数据落盘的边界,也就是 checkpoint 与 write pos中间是已记录的,当 write pos写完 id_logfile_3后,会回到id_logfile_0循环写,而追上 checkpomnit 后则需要先等数据进行落盘,等待 checkponit向后面移动一段距离再写。

Mysql分层架构_第3张图片

Mysql分层架构_第4张图片

1.bin log

redo log 因为大小固定,所以不能存储过多的数据,它只能用于未更新的数据落盘,而数据操作的备份恢复、以及主从复制是靠 bin log(如果数据库误删需要还原,那么需要某个时间点的数据备份以及bin log)。5.7默认记录的是操作语句涉及的每一行修改前后的行记录。

在更新到数据页缓存或者 Change Buffer 后,首先进行 redo log 的编写,编写完成后将 redo log 设为 prepare 状态,随后再进行 binlog 的编写,等到 binlog 也编写完成后再将 redo log 设置为 commit 状态。这是为了防止数据库宕机导致 binlog 没有将修改记录写入,后面数据恢复、主从复制时数据不一致。在断电重启后先检查 redo log 记录的事务操作是否为 commit 状态:

1、如果是 commit 状态说明没有数据丢失,判断下一个。

2、如果是 prepare 状态,检查 binlog 记录的对应事务操作(redo log 与 binlog 记录的事务操作有一个共同字段 XID,redo log 就是通过这个字段找到 binlog 中对应的事务的)是否完整(这点在前面 binlog 三种格式分析过,每种格式记录的事务结尾都有特定的标识),如果完整就将 redo log 设为 commit 状态,然后结束;不完整就回滚 redo log 的事务,结束。

总结

提示:这里对文章进行总结:
例如:以上就是今天要讲的内容,本文仅仅简单介绍了pandas的使用,而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。

你可能感兴趣的:(mysql,架构,数据库)