浅谈innodb架构

最新推荐文章于 2021-01-21 02:32:48 发布

原创最新推荐文章于 2021-01-21 02:32:48 发布 · 417 阅读

0 ·

CC 4.0 BY-SA版权

mysql 专栏收录该内容

4 篇文章

订阅专栏

本文深入探讨了MySQL的InnoDB存储引擎，详细介绍了事务的ACID特性及其操作，以及InnoDB的内存结构，如Buffer Pool、Redo log Buffer、Double Write等。此外，还讲解了InnoDB的磁盘文件组成，包括共享表空间、用户表空间和重做日志文件，强调了数据持久性和一致性的保障机制。

浅谈innodb架构（补充）

事物介绍
- 事物四大特性（ACID）
- 事物操作
InnoDB架构

事物介绍

作为一个关系型数据库，最重要的就是数据的持久一致，所以我们先来聊一聊事物！
事物在mysql中是由存储引擎实现的，而且支持事物的存储引擎并不多，既然说mysql，就主要用innodb存储引擎的事物！
事物处理可以用来维护数据库的完整性，保证成批的sql语句要么全部执行，要么全部失败。
事物管理对象---->DDL、DML等语句，默认是自动提交的（就是你不自己手动开启事物，提交事物的话，系统默认一句sql直接提交）

事物四大特性（ACID）

Atomicity–>原子性：构成事物的所有操作必须是一个逻辑单元，而且原子性关注状态，要么全部成功，要么全部失败
Consistency–>一致性：数据库在事物执行前后的状态必须都是稳定的或者一致的，而且一致性关注数据的可见性，中间状态的数据对外部不可见，只有最初状态和最终状态的数据对外可见
IsonIation–>隔离性：事物之间不会互相影响，由InnoDB的锁机制以及MVCC机制实现
Durability–>持久性：事物执行成功后必须全部写入磁盘

事物操作

显示开启事物：begin或者start trasaction ------>这两个显示开启并不会在执行此命令时开启事物，而是在你执行完此命令后，进行第一次DML或者DQL的时候正式开始事物
提交事物：commit或者commit work，提交标识数据更改永久性
回滚事物：rollback 或者rollback word 回滚标识撤销此事物的所有操作

InnoDB架构

摘自https://www.jianshu.com/p/1c1f83d0bb72

由图详细的显示了InnoDB存储引擎的体系架构，InnoDB存储引擎由，内存池，后台线程，磁盘文件三部分组成（OS PAGE CACHE是系统缓存）

InnoDB内存结构

Buffer Pool缓冲池（处理数据）

数据页和索引页（data page和index page）

page和InnoDB存储的最近处结构，也是InnoDB磁盘管理的最小单位
做DML时，缓存里的数据页和磁盘里的数据页不一致，该数据页就称为脏页

插入缓冲（insert Buffer）

负责主键排序索引树状插入算法

自适应哈希索引(Adaptive Hash Index)

hash结构，InnoDB会根据访问的频率和模式为热点页建立哈希索引，用来提高查询效率

锁信息（lock info）

行锁、表锁信息

数据字典信息（Data Dictionary）

元数据信息，包括表结构、数据库名、表名、字段的数据类型、视图、索引、表字段信息、存储过程、触发器等内容

Redo log Buffer重做日志缓冲区

重做日志：Redo log，存储数据的日志，一旦崩了则可以从日志找。
索引重做日志保证了数据的可靠性，InnoDB采用的是Write Ahead Log（预写日志）策略，就是当事物提交时，先写重做日志，然后再择时（CheckPoint）将脏页写入磁盘，如果发生了宕机导致了数据丢失，可以通过重做日志进行数据恢复。
比如：
begin；
update t set 。。。。；
commit；-----> 此步骤先保证Redo log file写成功，则commit成功
而怎么保证redo log file写成功呢？Force Log at Commit机制来实现，当你写redo log file时，为了确保每次都写入到重做日志文件，在每次重做日志缓冲写入重做日志后，必须调用一次fsunc操作（系统操作），保证将数据写入文件，而不是在系统缓存

重做日志的落盘机制

当设置该值为1时，每次事物提交都要做一次fsync，数据最安全，即使宕机也能保证重做日志的完整性
当设置值为2时，在提交事物时，只将数据落在系统缓冲（os page buffer）中，没有进行fsync操作，因此宕机则可能丢失事物
当设置为0时，事物提交不触发redo写操作，还是放在redo log buffer中，后台线程每秒一次刷盘，将redolog buffer写入到redo log file中，这样宕机可能会丢失1秒钟内的事物
所以还会是那个问题：安全的就最慢 —> 1 最快的最不安全----> 0

Double Write双写机制

Double Write带给了InnoDB存储引擎数据页的可靠性，其由两部分组成，一部分是内存中的Double Write Buffer 另一部分是磁盘上共享表空间连续的128页，他么两的大小都是2MB,当检查点触发，Buffer Pool中的脏页，就根据双写机制先将脏页数据复制到内存中的Double Write Buffer 中，之后通过Double Write Buffer 再分两次，每次1MB顺序的写入共享表空间的物理磁盘上（.ibdata），之后马上调用fsync函数同步磁盘，然后再将Double Write Buffer 中的页写入到各个表空间文件中（.ibd），如果在页写入磁盘的过程中崩溃，恢复时，InnoDB存储引擎可以从共享表空间中的double write中找到该页的一个副本，将其复制到表空间文件中。

CheckPoint（检查点）

检查点，表示脏页写入到磁盘的时机，所以检查点也就意味着脏数据的写入。
1、checkpoint的目的

   缩短数据库的恢复时间
   buffer pool空间不够用时，将脏页刷新到磁盘
   redolog不可用时，刷新脏页

2、检查点分类

1、sharp checkpoint：完全检查点 数据库正常关闭时，会触发把所有的脏页都写入到磁盘上
2、fuzzy checkpoint：正常使用时 模糊检查点，部分页写入磁盘。
   master thread checkpoint ： 以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回磁
盘，这个过程是异步的，
   flush_lru_list checkpoint ： 读取lru (Least Recently Used) list，找到脏页，写入磁盘。 最近最少使用
   async/sync flush checkpoint ： redo log file快满了，会批量的触发数据页回写，这个事件触发的时候
又分为异步和同步，不可被覆盖的redolog占log file的比值：75%--->异步、90%--->同步。
   dirty page too much checkpoint ： 默认是脏页占比75%的时候，就会触发刷盘，将脏页写入磁盘