阅读 82

MySQL架构设计--Innodb存储引擎

1. sql操作流程图(innodb存储引擎)

2. 流程图解析

1)前台操作触发mysql服务器执行请求

前台用户各种操作触发mysql执行,通过web项目中自带的数据库连接池:dbcp、c3p0、druid等,与数据库服务器建立网络连接

数据库连接池中的线程监听到请求后,将接收到的sql语句通过sql接口响应给查询解析器,查询解析器按照sql语法解析出查询哪些表的哪个字段,查询条件是啥;再通过查询优化器处理,选择该sql最优的一套执行计划,然后执行器负责调用存储引擎的一系列接口,执行该计划完成整个sql语句的执行

2)InnoDB存储引擎-缓冲池完成基本更新操作

具体执行这些执行计划得要存储引擎来完成,如图所示,首次更新user表中id=10的这条数据,缓冲池一开始肯定没有该条数据的,得要先从磁盘中将被更新的原始数据加载到缓冲池中

同时为了保证并发更新数据安全问题,会对这条数据先加锁,防止其他事务更新

接着将更新前的值先备份到undo log 中,便于回滚

最后更新缓存页中的数据为最新的数据,至此就完成了在缓冲池中的执行流程

3)Redo Log 和 BinLog保证事务的可靠性

缓冲池中更新完数据后,需要将本次更新的数据顺序写到redo log和bin log日志中(此时信息还在内存中,后续的刷盘策略如图所示),一般为了保证数据不丢失会配置双写策略,redo log 落盘后,写bin log 落盘,再将bin log 的文件名、文件所在路径信息以及commit标记同步顺序写到redo log中(其中以commit标记是否更新到redo log中,是判定事务是否提交成功的一个重要标准),redo log和bin log分别在物理和逻辑层面为本次事务、提供数据上的一致性保障,如图

4)将事务的操作持久化

前面的一系列操作后,InnoDB存储引擎后台还有一个IO线程,会在数据库压力的低峰期间,将缓冲池中被事务更新、但还没来得及写到磁盘中的数据(脏数据,因为磁盘数据和内存数据已经不一致了)给刷到磁盘中,完成事务的持久化,如图

3. buffer pool

1)内存结构

查询参数:innodb_buffer_pool_size,默认大小128M。

注意:buffer pool中缓存页对应磁盘中的数据页,另外还有一块内存关于数据的描述信息,大概是数据页的5%左右, 800字节左右,所以一块buffer pool实际内存要比128M大一点。

2)3大链表

  • free链表

buffer pool中并没有单独开辟空间来维护free链表,而是在 描述数据 中维护着两个指针,free_pre和free_next,分别向上一个free链表的节点,和下一个free链表的节点,构成了free链表。

数据加载到buffer pool中的缓存页中,把free链表上对那个的缓存页节点删除掉。

判断数据有没有加载到buffer pool中,还需要引入数据库自己维护的hash表数据结构,会用 表空间号+数据页号,作为一个key,缓存页的地址作为value。

  • flush链表

数据结构同free链表,用于刷脏,脏数据指的是缓存页中增删改的数据,把flush链表上的缓存页数据刷到磁盘

避免每次刷盘都刷整个buffer pool中所有数据。

数据刷入磁盘之后,该缓存页从flush链表上移除,重新添加到free链表上。

- lru链表(least recently used)

数据结构同free链表,记录着缓存页数据被操作的命中率,如果一个缓存页的数据经常被执行增删改操作,称之为高命中,排在链表头部,相反则排在尾部。

一条数据被操作的时候,该缓存页会被提升到lru链表的头部。

如果缓存页不够的话,会把lru尾部不常操作的数据刷入到磁盘,重新把缓存页添加到free链表中。

注意:由于mysql的预读机制和全表扫描,经常会把相邻的数据页和整个表的数据页加载到buffer pool中,引起的问题就是根本不会操作的数据占据了lru链表比较靠前的位置,而可能操作的数据被挤到了尾部,从而造成了尾部数据重新加载。

lru链表优化

参数:冷热数据比例innodb_old_blocks_pct 默认37

      冷区数据移动到热区数据的时间阈值innodb_old_blocks_time 默认1000毫秒

4. undo log

buffer pool中更新事务未提交的数据,mysql就宕机了,此时数据就需要回滚到未更新之前的状态,引入了undo log,记录了当前事务操作的逆向操作(也就是操作之前的数据),保证事务失败后数据的回滚。

在磁盘数据页加载到buffer pool中缓存页之后,数据更新之前,把逆向日志记录到redo log中。

5. redo log

buffer pool中更新事务提交的数据,如果还没来得及刷入磁盘,就断电了,这时候的数据在内存中,断掉就丢失了;所以引入了redo log机制,保证事务提交的时候,以日志的形式记录到redo log文件中,此时断电,重启后只需要把之前的事务根据redo log重做一次就好,保证事务提交的数据不丢失。

而且redo log采取的是日志追加的顺序写,性能比刷盘的随机写高很多。

redo log格式:--日志类型+表空间号+数据页号+偏移量+修改几个字节的值+具体的值。

注意:redo log 并不是一条一条的追加,而是引入了redo log block的数据结构,512k,类似于字节流设置多少字节操作一次一样;mysql启动的时候就会在buffer pool中申请一个redo log buffer空间用来存放redo log block,默认16M。

redo log buffer何时刷盘呢?

1)redo log buffer 写入的数据超过了总空间的一半

2)Innodb_flush_log_at_trx参数控制事务提交后的几种刷盘策略

3)后台线程每隔1s刷盘一次

4)mysql关闭的时候

文章分类
后端
文章标签