InnoDB 记录存储结构和索引页结构
行格式
mysql数据行除了记录表中定义的数据列外还有很多额外的字段列：
变长字段长度列表：比如VARCHAR(M)、VARBINARY(M)、 各种 TEXT 类型，各种 BLOB 类型，他们的长度是不固定的，所以我们在存储真实数据 的时候需要顺便把这些数据占用的字节数也存起来。如果该可变字段允许存储的 最大字节数超过 255 字节并且真实存储的字节数超过 127 字节，则使用 2 个字节， 否则使用 1 个字节。
Null值列表：表中的某些列可能存储 NULL 值，mysql用一个二进制列表来当前记录的列数据是否为null，如果列表值为0，代表是null，如果是1，代表不为null。
记录头：由8个字节共40位组成
| 列名 | 位数 | 作用 |
| 预留位1 | 1 | 暂未使用 |
| 预留位2 | 1 | 暂未使用 |
| delete_mark | 1 | 标记该记录是否被删除。当页面被删除时将值标记为1， |
| min_rec_mask | 1 | 非叶子节点中的最小记录会添加该标记 |
| n_owened | 4 | 每个槽内最大的记录才有值，表示当前所在槽拥有的记录行数。 |
| heap_no | 13 | 表示当前记录在页的位置信息，最小和最大的两条伪记录的编号分别时0和1. |
|
record_type
| 3 |
表示当前记录的类型，
0
表示普通记录，
1
表示
B+
树非叶子 节点记录，2
表示最小记录，
3
表示最大记录
|
|
next_record
| 16 |
表示下一条记录的相对位置。每个页面的所有记录组成一个从最小到最大的单向链表。最后一条记录的下一条记录指向最小记录
|
索引页格式
一个 InnoDB 数据页的存储空间大致被划分成了 7 个部分：
InnoDB 的体系结构
MySQL的记录存储在页中，每个页都是物理上连续的一段存储空间。连续的64个页组成了一个区，也就是1MB大小。每256个区称为一个组，第一个组最开始的 3 个页面的类型是固定的：用来登记整个表空间的一些整 体属性以及本组所有的区被称为 FSP_HDR，也就是 extent 0 ~ extent 255 这 256 个区，整个表空间只有一个 FSP_HDR。为了区分叶子节点和非叶子节点页面，所有的非叶子节点和叶子节点分别组成一个集合，称为段，即一个索引有两个段。
系统表空间
双写缓冲区/双写机制
缓冲双写机制工作原理
buffer pool
free链表的管理
缓存页的哈希处理
flush链表的管理
LRU链表的管理
SHOW VARIABLES LIKE 'innodb_old_blocks_pct'; -- lru链表冷数据区的比例，默认37
SHOW VARIABLES LIKE 'innodb_old_blocks_time'; -- lru链表冷数据区进热数据区的时间间隔，默认1000毫秒脏页刷盘机制
mysql有个专门的后台进程每隔一段时间负责把脏页刷新到磁盘。主要有两种途径：
1. 定期扫描lru链表尾部的一些页面，如果发现脏页则刷新到磁盘。这个页面数由innodb_lru_scan_depth来指定，这种刷 新页面的方式被称之为BUF_FLUSH_LRU。
2. 定期从flush链表中刷新一部分页面到磁盘，刷新的速率取决于当时系统是 不是很繁忙。这种刷新页面的方式被称之为BUF_FLUSH_LIST。
如果后台进程刷新脏页的进度比较慢导致buffer pool中没有空闲页，并且此时lru链表的冷数据区全是脏页，那么将不得不lru尾部的一个脏页刷新到磁盘，这种耍弄新单个页面到磁盘的方式被称 之为BUF_FLUSH_SINGLE_PAGE。
多个Buffer Pool实例
在高并发情况下，buffer pool的每个链表的维护都要加锁处理而性能不高。所以在buffer pool比较大且并发量较大的时候，可以把它拆分成多个小的buffer pool。它们都是独立的，独立的去申请内存空间，独立的管理各种链表，所以在多线程并发访问时并不会相互影响，从而提高并发处理能力。buffer pool的实例个数由innodb_buffer_pool_instances指定，最大为64。由于管理buffer pool也存在开销，所以它不是越多越好。一般情况下，如果innodb_buffer_pool_size小于1G，则innodb_buffer_pool_instances设置为多个也不生效；如果innodb_buffer_pool_size大于1G，则应设置nnodb_buffer_pool_instances使得每个buffer pool的值达到1G为最佳。在mysql5.7.5及以后的版本中，支持动态的调整buffer pool的大小。mysql在调整buffer pool的大小时是以chunk为单位进行增减内存的，chunk的默认大小为128M，只能在mysql启动时调整，以变量innodb_buffer_pool_chunk_size指定。
查看Buffer Pool的状态信息
SHOW ENGINE INNODB STATUS\G
Total memory allocated：代表Buffer Pool向操作系统申请的连续内存空间大小，包括 全部控制块、缓存页、以及碎片的大小。
Dictionary memory allocated：为数据字典信息分配的内存空间大小，注意这个内存空 间和Buffer Pool没啥关系，不包括在Total memory allocated中。
Buffer pool size：代表该Buffer Pool可以容纳多少缓存页，注意，单位是页！ Free buffers：代表当前Buffer Pool还有多少空闲缓存页，也就是free链表中还有多少 个节点。
Database pages：代表LRU链表中的页的数量，包含young和old两个区域的节点数量。
Old database pages：代表LRU链表old区域的节点数量。
Modified db pages：代表脏页数量，也就是flush链表中节点的数量。
Pending reads：正在等待从磁盘上加载到Buffer Pool中的页面数量。 当准备从磁盘中加载某个页面时，会先为这个页面在Buffer Pool中分配一个缓存页以及 它对应的控制块，然后把这个控制块添加到LRU的old区域的头部，但是这个时候真正的磁 盘页并没有被加载进来，Pending reads的值会跟着加1。
Pending writes LRU：即将从LRU链表中刷新到磁盘中的页面数量。
Pending writes flush list：即将从flush链表中刷新到磁盘中的页面数量。 Pending writes single page：即将以单个页面的形式刷新到磁盘中的页面数量。
Pages made young：代表LRU链表中曾经从old区域移动到young区域头部的节点数量。
Page made not young：在将innodb_old_blocks_time设置的值大于0时，首次访问或者后 续访问某个处在old区域的节点时由于不符合时间间隔的限制而不能将其移动到young区域 头部时，Page made not young的值会加1。 youngs/s：代表每秒从old区域被移动到young区域头部的节点数量。 non-youngs/s：代表每秒由于不满足时间限制而不能从old区域移动到young区域头部的节 点数量。
Pages read、created、written：代表读取，创建，写入了多少页。后边跟着读取、创 建、写入的速率。
Buffer pool hit rate：表示在过去某段时间，平均访问1000次页面，有多少次该页面已 经被缓存到Buffer Pool了。
young-making rate：表示在过去某段时间，平均访问1000次页面，有多少次访问使页面 移动到young区域的头部了。
not (young-making rate)：表示在过去某段时间，平均访问1000次页面，有多少次访问 没有使页面移动到young区域的头部。
LRU len：代表LRU链表中节点的数量。
unzip_LRU：代表unzip_LRU链表中节点的数量。
I/O sum：最近50s读取磁盘页的总数。
I/O cur：现在正在读取的磁盘页数量。
I/O unzip sum：最近50s解压的页面数量。
I/O unzip cur：正在解压的页面数量。Change Buffer
change buffer是buffer pool中的一块内存，默认25%，由innodb_change_buffer_max_size指定。它是一种应用于普通非唯一索引上为降低IO随机写频率的缓存技术。在mysql5.5之前叫inset buffer，只对插入操作做优化，后面对delete、update操作都支持。mysql在进行update操作时，如果相关的普通非唯一性索引页在buffer pool中，则直接修改；如果不存在，则在chang buffer 中记录要更新的相关信息，给客户端返回修改成功。当该索引页在下次被使用而不得不加载到buffer pool中时，将索引页与change buffer中的更新信息合并，以此避免了在修改时进行磁盘随机IO操作，达到提升效率的目的。
为什么写缓冲优化，仅适用于非唯一普通索引页呢？
因为唯一性索引在修改数据时必须先校验数据的唯一性，导致当时必须要找到相关的页面而不得不进行磁盘IO。在这种情况change buffer就排不上用场了。
change buffer的刷盘时机
- 访问这个数据页；
- 后台master线程会定期 merge；
- 数据库缓冲池不够用时；
- 数据库正常关闭时；
- redo log写满时；
change buffer的使用场景
- 数据库大部分是非唯一索引；
- 业务是写多读少，或者不是写后立刻读取；
mysql> show variables like '%change_buffer%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| innodb_change_buffer_max_size | 25 |
| innodb_change_buffering | all |
+-------------------------------+-------+
2 rows in set (0.00 sec)
#innodb_change_buffering：默认是all支持所有DML操作
#innodb_change_buffer_max_size：默认是25，即缓冲池的1/4。最大可设置为50,采用默认即可
1.5 监控指标
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
#这行显示了关于size（size 1代表了已经合并记录页的数量）、 free list（代表了插入缓冲中空闲列表长度）和seg size大小（seg size 2显示了当前insert buffer的长度，大小为27572*16K=440M左右）的信 息。0 merges代表合并插入的次数
Ibuf: size 1, free list len 0, seg size 2, 0 merges
#这个标签下的一行信息insert，delete mark，delete 分别表示merge操作合并了多少个insert buffer，delete buffer，purge buffer
merged operations:
insert 0, delete mark 0, delete 0
#这个标签下的一行信息表示当change buffer发生 merge时表已经被删除了，就不需要再将记录合并到辅助索引中
discarded operations:
insert 0, delete mark 0, delete 0
#因为没有update buffer，所以对一条记录进行update的操作可以分为两个过 程： # A：将记录标记为删除 # B：真正将记录删除 #因此，delete buffer对应update 操作的第一个过程，即将记录标记为删除， purge buffer对应update的第二个过程，即将记录真正地删除
扫一扫
301
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
