百度录入网站,顺德网站制作案例信息,全屏网站设计技巧,虚拟机电脑网页版大纲
1.InnoDB引擎架构
2.Buffer Pool
3.Page管理机制之Page页分类
4.Page管理机制之Page页管理
5.Change Buffer
6.Log Buffer 1.InnoDB引擎架构
(1)InnoDB引擎架构图
(2)InnoDB内存结构 (1)InnoDB引擎架构图
下面是InnoDB引擎架构图#xff0c;主要分为内存结构和磁…大纲
1.InnoDB引擎架构
2.Buffer Pool
3.Page管理机制之Page页分类
4.Page管理机制之Page页管理
5.Change Buffer
6.Log Buffer 1.InnoDB引擎架构
(1)InnoDB引擎架构图
(2)InnoDB内存结构 (1)InnoDB引擎架构图
下面是InnoDB引擎架构图主要分为内存结构和磁盘结构两大部分。 (2)InnoDB内存结构 2.Buffer Pool
(1)Buffer Pool基本概念
(2)如何判断数据页是否缓存在Buffer Pool (1)Buffer Pool基本概念
Buffer Pool是缓冲池的意思。Buffer Pool的作用是缓存表数据与索引数据减少磁盘IO提升效率。 Buffer Pool由缓存数据页(Page)和对缓存数据页进行描述的控制块组成。控制块存储着缓存页的表空间、数据页号、在Buffer Pool中的地址等。 Buffer Pool默认大小是128M以Page页为单位Page页默认大小16K。而控制块的大小约为数据页的5%大概是800字节。 注意Buffer Pool大小为128M指的就是缓存页的总大小。控制块则一般占5%所以每次会多申请6M的内存空间用于存放控制块。 (2)如何判断数据页是否缓存在Buffer Pool
MySQl中有一个哈希表数据结构key是表空间号 数据页号然后value就是缓存页对应的控制块。 当需要访问某个页的数据时会先从哈希表中根据表空间号 页号看看是否存在对应的缓存页。如果有则直接使用。如果没有则从Free链表中选出一个空闲的缓存页然后把磁盘中对应的页加载到该缓存页的位置。 3.Page管理机制之Page页分类
Buffer Pool的底层采用链表数据结构管理Page。在InnoDB访问表记录和索引时会在Buffer Pool中的Page页缓存以后使用同样的表记录和索引时就可以减少磁盘IO操作提升效率。 Page根据状态可以分为三种类型
一.Free Page空闲Page未被使用。
二.Clean Page被使用Page没被修改。
三.Dirty Page被使用Page已被修改。
脏页中的数据和磁盘的数据产生了不一致。 4.Page管理机制之Page页管理
(1)Free List空闲缓冲区
(2)Flush List需刷盘的缓冲区
(3)LRU List正在使用的缓冲区 针对上面的三种Page类型InnoDB会通过三种链表结构来维护和管理。 (1)Free List表示空闲缓冲区(管理Free Page)
一.Free链表的初始化
Buffer Pool初始化时会先向操作系统申请连续的内存空间然后把它划分成若干个控制块缓存页接着把所有空闲的缓存页对应的控制块作为节点放到一个链表中这个链表就是Free链表。 二.Free链表的基节点
Free链表中只有一个基节点是不记录缓存页信息的(单独申请空间)基节点存放了Free链表的头节点地址、尾节点地址和节点个数。 三.从磁盘加载数据页的流程
步骤1首先从Free链表中取出一个空闲的控制块(对应缓存页)。 步骤2然后把该缓存页对应的控制块信息填上如缓存页所在的表空间、数据页号之类的信息。 步骤3接着把该缓存页对应的Free链表节点(即控制块)从链表中移除表示该缓存页已经被使用了。 (2)Flush List表示需要刷新到磁盘的缓冲区(管理Dirty Page)
Flush List管理的Dirty Page会按修改时间排序。InnoDB引擎为了提高处理效率在每次修改缓存页后并非立刻把修改刷新到磁盘上而是在未来某个时间点进行刷新操作。 凡是被修改过的缓存页对应的控制块都会作为节点加入到Flush链表Flush链表的结构与Free链表的结构相似。 脏页既存在于Flush链表中也存在于LRU链表中但它们互不影响。LRU链表负责管理Page的可用性和释放Flush链表负责管理脏页的刷盘操作。 (3)LRU List表示正在使用的缓冲区(管理Clean Page和Dirty Page)
一.普通LRU算法
二.普通LRU链表的优缺点
三.改进型LRU算法
四.冷数据区的数据页何时会被转到到热数据区 缓冲区以midpoint为基点链表的前面部分称为热数据列表存放经常访问的数据占63%。链表的后面部分称为冷数据列表存放使用较少数据占37%。 一.普通LRU算法
LRU Least Recently Used(最近最少使用)就是末尾淘汰法。新数据从链表头部加入释放空间时从末尾淘汰。 步骤1当要访问某个不在Buffer Pool中的数据页时就把该数据页加载到Buffer Pool并且把其缓存页对应的控制块作为节点添加到LRU链表的头部。 步骤2当要访问某个在Buffer Pool中的数据页时就把其缓存页对应的控制块移动到LRU链表头部。 步骤3当需要释放空间时从最末尾淘汰。 二.普通LRU链表的优缺点
优点(热数据最快被获取)
所有最近使用的数据都在链表表头最近未使用的数据都在链表表尾可以保证热数据能最快被获取到。 缺点(全表扫描 预读机制)
如果发生全表扫描则可能将真正的热数据淘汰。由于MySQL中存在预读机制很多预读的页会被放到LRU链表的表头。如果这些预读的页没用到那么就可能会导致真正的热数据在尾部被淘汰。全表扫描的发生场景是没有建立合适的索引或查询时使用select *等。 三.改进型LRU算法
改进的LRU链表分为热数据和冷数据两个部分。往LRU链表加入元素时并不从表头插入而是从中间midpoint位置插入也就是从磁盘中新读出的数据会放在冷数据区的头部。 如果数据很快被访问那么Page就会向热数据列表头部移动如果数据没有被访问那么Page会逐步向冷数据列表尾部移动等待淘汰。 四.冷数据区的数据页何时会被转到到热数据区
在对某个处于冷数据列表的缓存页进行第一次访问时就会在它对应的控制块中记录下这个访问时间。 如果后续的访问时间与第一次访问的时间在某个时间间隔内那么该缓存页就不会从冷数据列表移动到热数据列表的头部否则就将该缓存页从冷数据列表移动到热数据列表的头部从而避免全表扫描带来的访问频率很低但占用大量缓存页的问题。 这个间隔时间由innodb_old_blocks_time控制默认是1s。这也就意味着对于从磁盘加载到LRU链表冷数据列表的缓存页来说如果第一次和最后一次访问的时间间隔小于1s则不会加入热数据列表。 5.Change Buffer
(1)Change Buffer基本概念
(2)Change Buffer的数据更新流程
(3)为什么写缓冲区仅适用于二级索引页
(4)什么情况下会进行merge
(5)Change Buffer的使用场景(写多读少) (1)Change Buffer基本概念
Change Buffer是写缓冲区用于优化对二级索引(辅助索引)页的更新。 对于DML操作如果请求的是辅助索引(非唯一键索引)且没有在缓冲池中那么不会立刻将数据页加载到Buffer Pool中而是会先在Change Buffer中记录数据的变更等未来数据被读取时再将数据合并恢复放到Buffer Pool以减少磁盘IO。 Change Buffer默认占Buffer Pool空间25%最大占50%。可根据读写业务量进行调整参数是innodb_change_buffer_max_size。 (2)Change Buffer的数据更新流程 情况1
对于唯一索引需要将数据页读入内存。然后判断没有冲突才插入更新值语句执行结束。 情况2
对于普通索引更新一条记录时步骤如下
步骤一如果该记录在Buffer Pool中存在那么就直接在Buffer Pool中修改进行一次内存操作。
步骤二如果该记录在Buffer Pool中不存在(没有命中)那么在不影响数据一致性的前提下InnoDB会将该记录的更新操作缓存在Change Buffer中先不用去磁盘查询数据从而避免一次磁盘IO。
步骤三当下次查询该记录时InnoDB才会将数据页读入内存然后执行Change Buffer中与该记录有关的操作。 (3)为什么写缓冲区仅适用于二级索引页
如果新增或修改发生在唯一索引中那么InnoDB必须要做唯一性校验。此时就必须查询磁盘进行一次IO操作。也就是会直接将记录查询到Buffer Pool中然后在缓冲池修改不需要在Change Buffer操作了。 如果新增或修改发生在非索引中那么InnoDB还是要做唯一性校验。此时也必须查询磁盘进行一次IO操作。 (4)什么情况下会进行merge
将Change Buffer中数据的变更应用到原数据页的过程称为merge。Change Buffer上的缓存数据是可以持久化的以下情况会进行持久化
一.访问这个数据页会触发merge
二.系统有后台线程会定期merge
三.在数据库正常关闭的过程中也会执行merge (5)Change Buffer的使用场景
Change Buffer的主要目的是将记录的变更操作缓存下来所以在merge发生前应当尽可能多的缓存变更信息这样Change Buffer的优势发挥得就越明显。 应用场景是写多读少的业务。此时页面在写完后马上被访问的概率较小Change Buffer使用效果最好。这种业务模型常见的就是账单类、日志类的系统。 6.Log Buffer
(1)Log Buffer的作用
(2)Log Buffer的刷盘策略
(3)Adaptive Hash Index (1)Log Buffer的作用
Log Buffer指的是日志缓冲区。 Log Buffer是用来保存要写入磁盘log文件(Redo/Undo)的log数据。Log Buffer可以优化每次更新操作后要写文件而产生的磁盘IO问题因为每次更新操作都是需要写log到redo log和undo log磁盘文件的。 Log Buffer日志缓冲区的内容会定期刷新到磁盘log文件中Log Buffer日志缓冲区满时会自动将其刷新到磁盘。当遇到BLOB或多行更新的大事务时增加日志缓冲区可节省磁盘IO。 Log Buffer主要是用于记录InnoDB引擎日志InnoDB在DML操作时会产生redo和undo日志。 Log Buffer空间满了会自动写入磁盘默认16M。可以通过将innodb_log_buffer_size参数调大减少磁盘IO频率。 (2)Log Buffer的刷盘策略
innodb_flush_log_at_trx_commit参数控制日志刷新行为默认为1。 一.innodb_flush_log_at_trx_commit 0
每隔1秒写日志文件Log Buffer和刷盘操作最多丢失1秒数据。写日志文件Log Buffer - OS cache - 刷盘OS Cache - 磁盘文件。 二.innodb_flush_log_at_trx_commit 1
事务提交立刻写日志文件和刷盘数据不丢失但是会频繁IO操作。 三.innodb_flush_log_at_trx_commit 2
事务提交立刻写日志文件Log Buffer每隔1秒钟进行刷盘操作。 (3)Adaptive Hash Index
自适应哈希索引用于优化对Buffer Pool数据的查询InnoDB存储引擎会监控对表索引的查找。 自适应哈希索引指的是如果观察到建立哈希索引可以带来速度的提升则建立哈希索引。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。
