MySQL执行流程

select语句执行流程

MySQL探索

增删改语句执行流程

update语句的整体执行流程和select语句是一样的。只是少了缓存的那一步骤。

mysql想完成数据的修改,会先从存储引擎层读取数据,把数据读取到服务层进行数据的修改,再通过存储引擎层把数据更新到数据库中。

mysql每次读取数据都会读取16384B的数据,默认是16KB的数据。一页的数据。

在innodb引擎中设计了 buffer pool 缓冲区。Mysql从磁盘中通过IO读取数据到buffer pool中,引擎从bffer pool中获取数据,然后修改,再把数据写入到buffer pool中。从而完成读写的操作,因为是基于内存的操作,所以速度是非常快的。

1

脏数据:buffer pool中的数据,还没有同步到磁盘中的数据称为脏数据。

innodb的脏页刷新机制说明:

1、当innodb中的脏页比例超过innodb_max_dirty_pages_pct_lwm的值时,这个时候innodb就会开始刷新脏页到磁盘。

2、当innodb中的脏页比例超过innodb_max_dirty_pages_pct_lwm的值,而且还超过innodb_max_dirty_pages_pct时innodb就会进入勤快刷新模式(agressively flush)这个模式下innodb会把脏页更快的刷新到磁盘。

3、还有一种情况叫做sharp checkpoint ,当innodb要重用它之前的redo文件时,就会把innodb_buffer_pool中所有与这个文件有关的页面都要刷新到磁盘;这样做就有可能引起磁盘的IO风暴了,轻者影响性能,重者影响可用性。

对于控制刷新机制的各个参数的说明:

1、innodb_max_dirty_pages_pct默认值为75,也就是说当脏页比例超过75%时才会进入勤快刷新模式。

2、innodb_max_dirty_pages_pct_lwm默认值是0,0对于innodb_max_dirty_pages_pct_lwm来说是一个特殊值,它表示不启用这个功能;由于没有启用这个功能,也就是说innodb_buffer_pool中的脏页比例会操持在75%左右。

Mysql会在后台使用若干线程,负责把buffer pool中的数据刷新到磁盘中去。

后台常用的线程:

master thread 主线程

IO thread IO操作的线程

Purge thread 清理数据和日志的线程

Page C1eaner thred 刷脏的线程

image-20230204150345380

查看buffer pool的大小,默认是128M

# 查询innodb buffer pool相关配置
show VARIABLES like '%innodb_buffer_pool%';

image-20230204150447678

数据存储到buffer pool中,默认是128M,如果buffer pool存满了,那么innodb引擎会使用改良的LRU算法清理数据。

注意:LRU算法是最近最久未使用法,mysql会对LRU的算法进行改良。

官网文档地址:https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html

冷热分离的方式:

新的数据刚进来的时候进入冷区域,如果下一秒被调用就进去热区域顶部,热区域的数据都会向下移动。

image-20230204150523330

redo log 日志

redo log日志是innodb存储引擎自带的。

避免服务器宕机或者其他突发事件,导致需要保存到数据库的数据还没来得及存储,所以才有了redo log。在mysql事务的层面上来说,redo log保证了数据的持久性。

2

问题:数据没有直接存入到磁盘上,而是先存入到buffer pool中,然后再刷入磁盘,目的是为了性能考虑,但是现在有需要存入到redo log 日志的磁盘文件中,这样性能不就下降了?

答案:性能肯定是会有一些影响,但是需要保证数据可恢复的能力。写入redo log磁盘文件中的速度会更快一些。

随机磁盘IO顺序磁盘IO的区别。

随机磁盘IO的情况是数据是会分散到不同的扇区去存储,因为底层是通过索引的顺序来存储,索引会存储到不同的扇区。那么更新数据的时候会增加寻道的时间,写入数据会变慢。

顺序磁盘IO是按着顺序追加写入的。 速度会快一些。

# 通过命令查看innodb_log相关的信息。
show VARIABLES like '%innodb_log%';

image-20230204151005642

默认是分成2组innodb_log_files_in_group,所以产生2个日志文件。

每个文件的大小默认是48Minnodb_log_file_size 固定的(可以修改),数据满了会产生覆盖的效果。

站在mysql事务的角度,redo log日志是事务持久性的保证。

image-20230204151106022

log buffer 刷盘机制(什么时候将记录的数据存储到磁盘中),官网说明

log buffer刷盘时间间隔

image-20230204151336792

每隔一秒刷盘一次,但是具体的刷盘策略由innodb_flush_log_at_trx_commit参数来决定。

image-20230204151353022

log buffer 刷盘机制:

innodb_flush_log_at_trx_commit:用来控制redo log刷新到磁盘的策略。

设置为1的时候,事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这种方式即使系统崩溃也不会丢失任何数据,但是因为每次提交都写入磁盘,IO的性能较差。

设置为0的时候,事务提交时不会将log buffer中日志写入到os buffer,而是每秒写入os buffer并调用fsync()写入到log file on disk中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的,当系统崩溃,会丢失1秒钟的数据。

设置为2的时候,每次提交都仅写入到os buffer,然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。

undo log日志

undo log日志是innodb存储引擎自带的。

undo log可以称为撤销日志或者回滚日志,站在事务的角度,undo log可以保证事务的原子性。

日志中记录的反向操作,例如:把username=”张三” 修改成了username=”赵四”,那么undo log中记录的是原来的值,即 username=”张三” 这样数据库再发生回滚操作的时候,可以把数据恢复回来。

本地存储位置:

image-20230204151519458

show VARIABLES like '%undo%';

image-20230204151553580

bin log 日志

bin log是mysql服务端的日志。

binary log 二进制日志,属于mysql服务层的日志。bin log是默认关闭的。

binlog是记录所有数据库表结构变更(例如CREATE、ALTER TABLE…)以及表数据修改(INSERT、UPDATE、DELETE…)的二进制日志。

binlog不会记录SELECT和SHOW这类操作,因为这类操作对数据本身并没有修改,但你可以通过查询通用日志来查看MySQL执行过的所有语句。

主要作用是主从复制和数据恢复的作用。

特点:

记录DDL和DML的语句,属于逻辑日志

没有固定大小限制,内容可以追加

Server层实现,可以被所有存储引擎使用

用于数据恢复和主从复制。

show GLOBAL VARIABLES like '%log_bin%';

image-20230204151719392

bin log主从复制的原理流程图:

3

总结

result

内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/beishanqingyun/p/17095270.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!