001_InnoDB引擎详解

最新推荐文章于 2024-09-11 10:18:51 发布

GeeKiller

最新推荐文章于 2024-09-11 10:18:51 发布

阅读量105

点赞数

分类专栏： mysql 文章标签： mysql 数据库 java

本文链接：https://blog.csdn.net/qq_32057039/article/details/129528170

版权

mysql 专栏收录该内容

9 篇文章 1 订阅

订阅专栏

存储结构

1). 表空间

表空间是InnoDB存储引擎逻辑结构的最高层，如果用户启用了参数 innodb_file_per_table(在
8.0版本中默认开启) ，则每张表都会有一个表空间（xxx.ibd），一个mysql实例可以对应多个表空
间，用于存储记录、索引等数据。

2). 段

段，分为数据段（Leaf node segment）、索引段（Non-leaf node segment）、回滚段
（Rollback segment），**InnoDB是索引组织表，数据段就是B+树的叶子节点，索引段即为B+树的 **
**非叶子节点。段用来管理多个Extent（区）。 **

3). 区

区，表空间的单元结构，每个区的大小为1M。默认情况下，** InnoDB存储引擎页大小为16K，即一 **
**个区中一共有64个连续的页。 **

4). 页

页，是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为 16KB。为了保证页的连续性，
InnoDB 存储引擎每次从磁盘申请 4-5 个区。

5). 行

行，InnoDB 存储引擎数据是按行进行存放的。
在行中，默认有两个隐藏字段：
Trx_id：每次对某条记录进行改动时，都会把对应的事务id赋值给trx_id隐藏列。
Roll_pointer：每次对某条引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息

架构

Mysql 从 5.5.6 开始默认使用 InnoDB 存储引擎，擅长事务处理，具有崩溃恢复特性，在日常开发
中使用非常广泛。下面是InnoDB架构图，左侧为内存结构，右侧为磁盘结构。

内存结构

从上面左侧我们可以看出来，内存结构主要包含4部分：Buffer Pool、Change Buffer、Adaptive Hash Index 、Log Buffer。

InnoDB 存储引擎基于磁盘文件存储的，访问物理硬盘和内存，速度相差很大，所以，为了减少磁盘的访问，需要将经常访问的数据加载到缓存池，避免每次都访问磁盘，减少磁盘IO。

1）Buffer Pool

缓存池 Buffer Pool 是主内存的一片区域，里面可以缓存磁盘上经常使用的数据，在进行增删查改的时候，可以先对缓存区的数据进行操作，然后再以一定的频率刷新到磁盘，减少磁盘IO ,加快处理速度。

Buffer Pool 以页为单位，缓存最热的数据页和索引页。

缓冲池以Page页为单位，底层采用链表数据结构管理Page。根据状态，将Page分为三种类型：
• free page：空闲page，未被使用。
• clean page：被使用page，数据没有被修改过。
• dirty page：脏页，被使用page，数据被修改过，也中数据与磁盘的数据产生了不一致。

2) Change Buffer

change buffer 写缓存区;
在MySQL5.5之前，叫插入缓冲(insert buffer)，只针对insert做了优化；现在对delete和update也有效，叫做写缓冲(change buffer)。

它是一种应用在非唯一普通索引页(non-unique secondary index page)不在缓冲池中，对页进行了写操作，并不会立刻将磁盘页加载到缓冲池，而仅仅记录缓冲变更(buffer changes)，等未来数据被读取时，再将数据合并(merge)恢复到缓冲池中的技术。写缓冲的目的是降低写操作的磁盘IO，提升数据库性能。

如上图，如果修改的页号40不在缓存区，没有写缓冲区的流程为：
（1）先把需要为40的索引页，从磁盘加载到缓冲池，一次磁盘随机读操作；
（2）修改缓冲池中的页，一次内存操作；
（3）写入redo log，一次磁盘顺序写操作；
而开启写缓冲区之后：
（1）在写缓冲中记录这个操作，一次内存操作；
（2）写入redo log，一次磁盘顺序写操作；

为什么针对非唯一普通索引页
唯一索引
所有的更新操作都要先判断这个操作是否违反唯一性约束。而这必须要将数据页读入内存才能判断。
如果都已经读入到内存了，那直接更新内存会更快，就没必要使用 change buffer 了。
因此，唯一索引的更新就不能使用 change buffer，实际上也只有普通索引可以使用。
普通索引
不需要判断唯一性，正常使用 change buffer 更新。

将 change buffer 中的操作合并到原数据页，得到最新结果的过程称为 merge。
以下情况会触发merge：

     - 访问这个数据页；
     - 后台master线程会定期 merge；
     - 数据库缓冲池不够用时；
     - 数据库正常关闭时；
     - redo log写满时；

3) Adaptive Hash Index

自适应hash索引，用于优化对Buffer Pool数据的查询。MySQL的innoDB引擎中虽然没有直接支持 hash索引，但是给我们提供了一个功能就是这个自适应hash索引。因为前面我们讲到过，hash索引在进行等值匹配时，一般性能是要高于B+树的，因为hash索引一般只需要一次IO即可，而B+树，可能需要几次匹配，所以hash索引的效率要高，但是hash索引又不适合做范围查询、模糊匹配等。

InnoDB存储引擎会监控对表上各索引页的查询，如果观察到在特定的条件下hash索引可以提升速度，则建立hash索引，称之为自适应hash索引。

**自适应哈希索引，无需人工干预，是系统根据情况自动完成。 **
参数： adaptive_hash_index

4) Log Buffer

Log Buffer：日志缓冲区，用来保存要写入到磁盘中的log日志数据（redo log 、undo log），
默认大小为 16MB，日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事
务，增加日志缓冲区的大小可以节省磁盘 I/O。
参数:
innodb_log_buffer_size：缓冲区大小
innodb_flush_log_at_trx_commit：日志刷新到磁盘时机，取值主要包含以下三个：
0: 每秒将日志写入并刷新到磁盘一次。
1: 日志在每次事务提交时写入并刷新到磁盘，默认值。
2: 日志在每次事务提交后写入，并每秒刷新到磁盘一次。

参考文档：
https://blog.csdn.net/shenjian58/article/details/93691224?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-93691224-blog-108031299.pc_relevant_3mothn_strategy_recovery&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-93691224-blog-108031299.pc_relevant_3mothn_strategy_recovery&utm_relevant_index=1