Innodb-内存架构与特性

参考文档

Innodb特性buffer_pool

http://mysql.taobao.org/monthly/2017/05/01/?spm=a2c4e.11153940.blogcont281249.10.5156506e7F6GpK

一.Innodb结构图

---

---

---

二.Innodb-内存结构

Innodb缓冲池

• Innodb是基于磁盘存储的，并将其中的记录按照页（默认16K）的方式进行管理，（基于磁盘的数据库系统Disk-baseDatabase）。
• 数据库系统中由于CPU速度与磁盘速度之间差距甚远，所以基于磁盘的数据库系统通常使用缓冲池（buffer pool）的技术来提高数据库的整体性能。
• 缓冲池就是一块内存区域，通过内存的速度来弥补磁盘速度较慢对数据库的影响。
• 要注意的是数据库中对于数据页的修改操作都是在缓冲池中完成的。
• 修改数据时，先修改缓冲池中的页数据，然后刷新到磁盘，并不是每次都刷新而是通过Checkpoint机制刷新到磁盘。
• 数据页类型：索引页、数据页、undo页、插入缓冲(insert buffer)、自适应哈希索引、锁信息、数据字典信息等。

缓冲池LRU算法（Latest，Recent Used）最近最少使用算法

相关参数：

innodb_old_blocks_pct    | 37   旧数据和新数据页的分界线，默认设置为37%，意味旧数据页占整个LRU列表的37%
innodb_old_blocks_time  | 1000 单位毫秒（默认1s）

Innodb在读取新的数据页时，并不是直接将这个数据页直接放到LRU列表的首部（如果直接放到首部，会导致之前正在使用的热数据被刷出列表），而是通过midpoint点，放入midpoint位置（innodb_old_blocks_pct空值）。midpoint之前的位置就是new列表，之后的位置就是old列表

Q：为什么热数据不直接放到LRU列表的首部？

这是由于某些慢语句可能需要全表扫描，这种情况以及类似的需要扫描大量数据的情况下，如果按照朴素的LRU算法，将磁盘上的数据页都读到LRU中，直接放到LRU列表的首部，就会将LRU列表中正在使用的热数据被刷新出列表，如果这个SQL只是使用了一次就不再使用了。那么现在LRU列表中的数据大部分就是不再使用的冷数据。下次读取数据，就要再次去磁盘中读取，加大了IO。

Q：那么如何规定新读进来的数据页放在LRU的规则？

除了上面制定LRU中new列表和old列表的分界线之外，还有一个参数，innodb_old_blocks_time  改参数的含义：读进来的新数据页先放入midpoint位置的冷端（冷端的头部），如果这个数据页在这个冷端能挺过改参数指定的时长，就将这个数据页放到热端（热端的尾部）。

mysql5.7对于LRU算法的改进

https://yq.aliyun.com/articles/281249

LRU List，Free List，Flush List

• LRU List:这个是InnoDB中最重要的链表。所有新读取进来的数据页都被放在上面。链表按照最近最少使用算法排序，最近最少使用的节点被放在链表末尾，如果Free List里面没有节点了，就会从中淘汰末尾的节点。LRU List还包含没有被解压的压缩页，这些压缩页刚从磁盘读取出来，还没来的及被解压。LRU List被分为两部分，默认前5/8为young list，存储经常被使用的热点page，后3/8为old list。新读入的page默认被加在old list头，只有满足一定条件后，才被移到young list上，主要是为了预读的数据页和全表扫描污染buffer pool。
• Free List：数据库启动时LRU表为空，页均存放在Free List中。需要使用时从该表中获取。如果需要从数据库中分配新的数据页，直接从上获取即可。InnoDB需要保证Free List有足够的节点，提供给用户线程用，否则需要从FLU List或者LRU List淘汰一定的节点。InnoDB初始化后，Buffer Chunks中的所有数据页都被加入到Free List，表示所有节点都可用。
• Flush List管理缓存中被修改过的页。这个链表中的所有节点都是脏页，也就是说这些数据页都被修改过，但是还没来得及被刷新到磁盘上。在FLU List上的页面一定在LRU List上，但是反之则不成立。一个数据页可能会在不同的时刻被修改多次，在数据页上记录了最老(也就是第一次)的一次修改的lsn，即oldest_modification。不同数据页有不同的oldest_modification，FLU List中的节点按照oldest_modification排序，链表尾是最小的，也就是最早被修改的数据页，当需要从FLU List中淘汰页面时候，从链表尾部开始淘汰。加入FLU List，需要使用flush_list_mutex保护，所以能保证FLU List中节点的顺序。

相关监控：

通过 show engine innodb status \G

----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 1117782016
Dictionary memory allocated 234666
Internal hash tables (constant factor + variable factor)
    Adaptive hash index 17740608     (17706944 + 33664)
    Page hash           139112 (buffer pool 0 only)
    Dictionary cache    4661402     (4426736 + 234666)
    File system         854280     (812272 + 42008)
    Lock system         2659448     (2657176 + 2272)
    Recovery system     0     (0 + 0)
Buffer pool size   65528
Buffer pool size, bytes 1073610752
Free buffers       65014
Database pages     514
Old database pages 0
Modified db pages  0
Pending reads      0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 476, created 38, written 347
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 514, unzip_LRU len: 0   LRU列表中包含了unzip_LRU的项
I/O sum[]:cur[], unzip sum[]:cur[]
----------------------

主要看两个指标：

youngs/s：使数据页边年轻的此时（不是页数）过大

• pct过大 不容易被刷出来
• time过小

non-youngs/：使数据页边老的次数（不是页数）过大

• 可能存在严重的全表扫描
• 也可能是pct的设置过小
• 也可能是times设置的过大

---

unzip_LRU

这个链表中存储的数据页都是解压页，也就是说，这个数据页是从一个压缩页通过解压而来的。

Innodb从1.0开始支持压缩也的功能。原本16KB的页可以压缩为1KB，2KB，4KB，8KB，对于这些非16KB的页是同坐unzip_LRU来管理的。

Q：压缩后的数据页大小可能都不一样，那么如果需要从缓冲池中申请的页大小为4KB，如何申请？

A: 1.检查4KB的unzip_LRU列表，检查是否有可用的空闲页

2.如果有，直接使用

3.否则，检查8KB的unzip_LRU列比哦啊

4.如果能够得到空闲页，将页分成2个4KB的页，存放到4KB的unzip_LRU列表中

5.如果不能得到空闲页，从LRU列表中申请一个16KB的页，将页分为一个8KB和2个4KB的页，分别存放到对应的unzip_LRU列表中

缓冲池相关监控

1.show engine innodb status \G

2.information_schema

mysql> SHOW TABLES FROM INFORMATION_SCHEMA LIKE 'INNODB_BUFFER%';
+-----------------------------------------------+
| Tables_in_INFORMATION_SCHEMA (INNODB_BUFFER%) |
+-----------------------------------------------+
| INNODB_BUFFER_PAGE                            |保存有关InnoDB 缓冲池中每个页面的信息
| INNODB_BUFFER_POOL_STATS                      |提供缓冲池状态信息。许多相同的信息由SHOW ENGINE INNODB STATUS输出提供 ，或者可以使用 InnoDB缓冲池服务器状态变量获得
| INNODB_BUFFER_PAGE_LRU                        |保存有关InnoDB 缓冲池中页面的信息，特别是它们在LRU列表中的排序方式，它确定哪些页面在缓冲池变满时从缓冲池中逐出
+-----------------------------------------------+

查询INNODB_BUFFER_PAGE或 INNODB_BUFFER_PAGE_LRU表可能会影响性能。除非您了解性能影响并确定其可接受，否则请勿在生产系统上查询这些表。为避免影响生产系统的性能，请重现要调查的问题并在测试实例上查询缓冲池统计信息。

一些查询：

查询INNODB_BUFFER_PAGE表中的系统数据

此查询通过排除TABLE_NAME值为 NULL或者包含表名中的斜杠/ 或句点的页面来提供包含系统数据的页面的近似计数 .，表示用户定义的表。

mysql>  SELECT COUNT(*) FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE WHERE TABLE_NAME IS NULL OR (INSTR(TABLE_NAME, '/') = 0 AND INSTR(TABLE_NAME, '.') = 0);
+----------+
| COUNT(*) |
+----------+
|    65497 |
+----------+

此查询返回包含系统数据的大致页数，缓冲池页的总数以及包含系统数据的页的大致百分比。

SELECT
       (SELECT COUNT(*) FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       WHERE TABLE_NAME IS NULL OR (INSTR(TABLE_NAME, '/') = 0 AND INSTR(TABLE_NAME, '.') = 0)
       ) AS system_pages,
       (
       SELECT COUNT(*)
       FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       ) AS total_pages,
       (
       SELECT ROUND((system_pages/total_pages) * 100)
       ) AS system_page_percentage;

查询PAGE_TYPE值来确定缓冲池中的系统数据类型。例如，以下查询PAGE_TYPE在包含系统数据的页面中返回八个不同的 值：

SELECT DISTINCT PAGE_TYPE FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       WHERE TABLE_NAME IS NULL OR (INSTR(TABLE_NAME, '/') = 0 AND INSTR(TABLE_NAME, '.') = 0);

INNODB_BUFFER_PAGE表中查询用户数据

此查询通过计算TABLE_NAME值为NOT NULL和的页面来提供包含用户数据的页面的近似计数 NOT LIKE '%INNODB_SYS_TABLES%'。

SELECT COUNT(*) FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       WHERE TABLE_NAME IS NOT NULL AND TABLE_NAME NOT LIKE '%INNODB_SYS_TABLES%';

返回包含用户数据的大致页数，缓冲池页面的总数以及包含用户数据的页面的大致百分比

SELECT
       (SELECT COUNT(*) FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       WHERE TABLE_NAME IS NOT NULL AND (INSTR(TABLE_NAME, '/') > 0 OR INSTR(TABLE_NAME, '.') > 0)
       ) AS user_pages,
       (
       SELECT COUNT(*)
       FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       ) AS total_pages,
       (
       SELECT ROUND((user_pages/total_pages) * 100)
       ) AS user_page_percentage;

此查询使用缓冲池中的页面标识用户定义的表

SELECT DISTINCT TABLE_NAME FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       WHERE TABLE_NAME IS NOT NULL AND (INSTR(TABLE_NAME, '/') > 0 OR INSTR(TABLE_NAME, '.') > 0)
       AND TABLE_NAME NOT LIKE '`mysql`.`innodb_%';

查询INNODB_BUFFER_PAGE表中的索引数据

有关索引页的信息，请INDEX_NAME使用索引名称查询 列。例如，以下查询返回表中emp_no定义的索引 的页数和页面总数据大小 employees.salaries：

SELECT INDEX_NAME, COUNT(*) AS Pages,
       ROUND(SUM(IF(COMPRESSED_SIZE = 0, @@GLOBAL.innodb_page_size, COMPRESSED_SIZE))/1024/1024)
       AS 'Total Data (MB)'
       FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       WHERE INDEX_NAME='emp_no' AND TABLE_NAME = '`employees`.`salaries`';

此查询返回employees.salaries表中定义的所有索引的页数和页面总数据大小

SELECT INDEX_NAME, COUNT(*) AS Pages,
       ROUND(SUM(IF(COMPRESSED_SIZE = 0, @@GLOBAL.innodb_page_size, COMPRESSED_SIZE))/1024/1024)
       AS 'Total Data (MB)'
       FROM INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
       WHERE TABLE_NAME = '`employees`.`salaries`'
       GROUP BY INDEX_NAME;

具体参考官方文档：

https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-buffer-pool-tables.html#innodb-information-schema-buffer-pool-stats-example

相关的状态变量：

+-----------------------------------------+--------------------------------------------------+
| Variable_name                           | Value                                            |
+-----------------------------------------+--------------------------------------------------+
| Innodb_buffer_pool_dump_status          | Dumping of buffer pool not started               |
| Innodb_buffer_pool_load_status          | Buffer pool(s) load completed at 181126 10:00:00 |
| Innodb_buffer_pool_resize_status        |                                                  |
| Innodb_buffer_pool_pages_data           | 1852                                             |
| Innodb_buffer_pool_bytes_data           | 30343168                                         |
| Innodb_buffer_pool_pages_dirty          | 3                                                |
| Innodb_buffer_pool_bytes_dirty          | 49152                                            |
| Innodb_buffer_pool_pages_flushed        | 4356                                             |
| Innodb_buffer_pool_pages_free           | 63676                                            |
| Innodb_buffer_pool_pages_LRU_flushed    | 0                                                |
| Innodb_buffer_pool_pages_made_not_young | 0                                                |
| Innodb_buffer_pool_pages_made_young     | 0                                                |
| Innodb_buffer_pool_pages_misc           | 0                                                |
| Innodb_buffer_pool_pages_old            | 0                                                |
| Innodb_buffer_pool_pages_total          | 65528                                            |
| Innodb_buffer_pool_read_ahead_rnd       | 0                                                |
| Innodb_buffer_pool_read_ahead           | 0                                                |
| Innodb_buffer_pool_read_ahead_evicted   | 0                                                |
| Innodb_buffer_pool_read_requests        | 52000                                            |
| Innodb_buffer_pool_reads                | 477                                              |
| Innodb_buffer_pool_wait_free            | 0                                                |
| Innodb_buffer_pool_write_requests       | 39180                                            |
| Innodb_buffered_aio_submitted           | 0                                                |
+-----------------------------------------+--------------------------------------------------+

三.后台线程

1.master thread

具有最高的线程优先级级别,内部有多个loop组成:

主循环 mian loop

后台循环background loop

刷新循环 flush loop

暂停循环 suspend loop

主要负责将脏缓存页刷新到数据文件，执行purge操作，触发检查点checkponit，合并插入缓冲区insert buffer

innodb 1.0.x 版本之前的master thread

每秒一次的操作:

• 日志缓冲刷新到磁盘,即使该事务没有提交(总是)
• 合并插入缓冲(可能)判断前一秒内io是否小于5次,如果小于,认为当前io压力小,可以执行insert buffer合并
• 最多刷新100个innodb的缓冲池中的脏页到磁盘(可能)
• 如果当前没有用户活动,就切换到background loop(可能) 根据buf_get_modified_pct 大小决定,如果超过90%的时候惠认为需要做磁盘同步操作,将100个脏页刷新到磁盘控制参数:innodb_max_dirty_pages_pct.

每10秒一次的操作:

• 刷新100个脏页(可能) 判断过去10秒内io是否小于200,如果小于,认为当前io能力足够,将刷新100个脏页
• 合并最多5个插入缓冲(总是) 刷完脏页后紧接着合并insert buffer,总会执行
• redo日志刷新到磁盘(总是)
• 删除无用的undo log(总是) 每次最多删除20个undo页
• 刷新100个或者10个脏页到磁盘(总是) 根据buf_get_modified_pct判断,如果>70%,刷100个脏页,如果<70%,刷10个脏页

以上是主循环

如果没有用户活动(数据库空闲)或者数据库关闭(suhtdown)就会切换到,background loop

• 删除没用的undo页(总是)
• 合并20个insert buffer(总是)
• 跳回main loop(总是)
• 不断刷新100个页知道符合条件(可能,跳转到flush loop中完成)

如果flush loop中也没事做了,就切换到supspend loop 将master thread挂起,等事件发生.

innodb 1.2.X版本之前的master thread

改进点1:

不再按照规定值刷新(之前最多1秒内只能处理100个脏页合并20个insert buffer)

而是按照参数innodb_io_capacity(表示io吞吐量,默认值200)做参考,对于刷新页的数量,按照参数规定的百分比控制:合并insert buffer时,数量为参数的25%,刷脏页时数量为参数设定值

改进点2:

设置innodb_max_dirty_pages_pct默认值为75%,因为之前的90%才刷脏页而且每次只能刷100个,如果内存很大,数据库压力很大,反而降低了刷脏页的效率,数据库恢复阶段可能需要更多的时间.

改进点3:

innodb 1.0.X 新增自适应刷新脏页,通过参数innodb_adaptive_fluhsing控制,根据redo log产生速度来决定合适刷新脏页数量,即使脏页比例小于innodb_max_dirty_pages_pct,也会刷新一定的脏页

改进点4:

每次full purge时最多刷新20个undo页,1.0.X版本后引入参数:innodb_purge_batch_size 来修改这个数量

innodb 1.2.X 版本的master thread

分离出一个单独的page cleaner thread ,减轻master thread的工作,提高系统并发性

2.purge thread

回收undo页

净化线程，MySQL5.5之后用单独的purge thread执行purge操作

参数控制:

innodb_purge_threads

3.page cleaner thread

innodb 1.2.x引入,刷新脏页(从master thread中分出来)

4.IO thread

innodb使用大量异步IO(Async IO)

参数:

innodb_read_io_threads

innodb_write_io_threads

redo log刷新机制

1:master thread 每一秒刷新

2.每个事务提交的时候刷新

3.redo log buffer 剩余空间小于1/2时刷新

四.文件系统

Innodb是以页为基本单位管理存储空间的，默认的页大小为16KB.

1.系统表空间(system tablespace)

这个所谓的系统表空间可以对应文件系统上一个或多个实际的文件，默认情况下，InnoDB会在数据目录下创建一个名为ibdata1.大小为12M的文件

对应参数:

[server]

innodb_data_file_path=data1:512M;data2:512M:autoextend

这样在MySQL启动之后就会创建这两个512M大小的文件作为系统表空间，其中的autoextend表明这两个文件如果不够用会自动扩展data2文件的大小

我们也可以把系统表空间对应的文件路径不配置到数据目录下，甚至可以配置到单独的磁盘分区上，涉及到的启动参数就是innodb_data_file_path和innodb_data_home_dir

参数文档:https://blog.csdn.net/demonson/article/details/79863166

2.独立表空间(file-per-table tablespace)

共享表空间越来越大,会对IO产生瓶颈,

控制参数

innodb_file_per_table,

开启后每张表的表空间只存放自己的：数据，索引和插入缓冲BITMAP页。其它信息仍放在默认表空间。

 其它信息如：回滚(undo)信息、插入缓冲索引页、系统的事物信息、二次写缓冲(Double write buffer)等。

 

共享表空间和独立表空间的优缺点对比:https://blog.csdn.net/qq_28752033/article/details/84024454?utm_source=distribute.pc_relevant.none-task

 

共享表空间和独立表空间的转换

ALTER TABLE 表名 TABLESPACE [=] innodb_file_per_table; 共享表空间-》独立表空间

ALTER TABLE 表名 TABLESPACE [=] innodb_system;          独立表空间-》共享表空间

 

3.其他表空间

 

随着MySQL的发展，除了上述两种老牌表空间之外，现在还新提出了一些不同类型的表空间，比如通用表空间（general tablespace）、undo表空间（undo tablespace）、临时表空间（temporary tablespace）