(十二)MySQL之内存篇：深入探寻数据库内存与Buffer Pool的奥妙！-阿里云开发者社区

引言

MySQL是基于磁盘工作的，这句几乎刻在了每个后端程序员DNA里，但它真的对吗？其实答案并不能盖棺定论，你可以说MySQL是基于磁盘实现的，这点我十分认同，但要说MySQL是基于磁盘工作，这点我则抱否定的态度，至于为什么呢？这跟咱们本章的主角：Buffer Pool有关，Buffer Pool是什么？还记得咱们在《MySQL架构篇》中聊到的缓存和缓冲区么，其中所提到的写入缓冲区就位于Buffer Pool中。

不过在具体分析它之前，先结合MySQL的整体架构，来聊一聊MySQL的内存。

一、结合MySQL架构聊一聊它的内存

经过《MySQL架构篇》的学习后，咱们已经熟悉了MySQL的整体架构，也包括在《SQL执行篇》中，站在一条SQL的角度进一步加深了对各组件的印象，但其中并未讲明白MySQL的工作时的内存结构，哪本章就先来盘一盘这块内容。

闲话少说，先上个图，毕竟正所谓：“开局一张图，装备全靠打”，如下：

注意观察，实际MySQL启动后内存结构略显复杂，但大体可分为MySQL工作组件、线程本地内存、MySQL共享内存、存储引擎缓冲区四大板块。

实际上MySQL内存模型和JVM类似，JVM内存主要会划分为线程共享区和线程私有区，而上图中的MySQL内存区域，左边则是线程私有区域，每条工作线程中都会分配的区域，各线程之间互不影响，而右边的三大板块，则属于线程共享区域，即所有线程都可访问的内存。

当然，线程共享区这块也会细分，右边上面的两个板块，都属于MySQL-Server层使用的内存，也就意味着这两块内存是所有引擎都共享的区域，而最下面这个区域，每个存储引擎都不相同，也就是InnoDB会构建自己的Buffer缓冲区，MyISAM也会构建自己的缓冲区。

Ok~，大概理解MySQL的内存构成后，下面一起简单聊一聊这四个内存区域。

1.1、MySQL Server - 工作组件

这个比较容易理解，也就是对应着MySQL架构图中的组件层，如下：

因为后续客户端连接时，都需要经过一系列的连接工作，处理SQL时也需要经过一系列的解析、验证、优化工作，所以MySQL会在启动时，会先将这些工作组件初始化到内存中，方便后续处理客户端的操作。

这里很简单，只需要额外注意一点即可，就是数据库的连接池中，存的到底是什么？存的实际上就是数据库连接对象，MySQL内部的连接对象，其中包含了客户端连接信息，如客户端IP、登录的用户、所连接的DB....等这类信息，同时这些连接对象在内部会绑定一条工作线程，因此你也可以将它理解成是一个线程池！MySQL复用连接的本质，实则是在复用线程，出现一个新的客户端连接时，首先会根据客户端信息为其创建连接对象，然后再复用连接池中的空闲线程。

但MySQL工作线程的本地内存中包含了很多东西，所以下面简单聊一聊。

1.2、工作线程的本地内存

工作线程的本地内存区域，也被称之为线程私有区，即MySQL在创建每条线程时，都会为其分配这些内存：

但这一大长排到底是啥意思呢，简单的说明一下其中每个区域的含义：

thread_stack：线程堆栈，主要用于暂时存储运行的SQL语句及运算数据，和Java虚拟机栈类似。
sort_buffer：排序缓冲区，执行排序SQL时，用于存放排序后数据的临时缓冲区。
join_buffer：连接缓冲区，做连表查询时，存放符合连表查询条件的数据临时缓冲区。
read_buffer：顺序读缓冲区，MySQL磁盘IO一次读一页数据，这个是顺序IO的数据临时缓冲区。
read_rnd_buffer：随机读缓冲区，当基于无序字段查询数据时，这里存放随机读到的数据。
net_buffer：网络连接缓冲区，这里主要是存放当前线程对应的客户端连接信息。
tmp_table：内存临时表，当SQL中用到了临时表时，这里存放临时表的结构及数据。
bulk_insert_buffer：MyISAM批量插入缓冲区，批量insert时，存放临时数据的缓冲区。
bin_log_buffer：bin-log日志缓冲区，《日志篇》提到过的，bin-log的缓冲区被设计在工作线程的本地内存中。

可以看到，在工作线程的本地内存中，除开最基本的线程堆栈外，MySQL还往内部“塞了”一堆东西，这些东西在不同的SQL运行时，都有各自的作用，但基本上是为了更好的保存临时数据而设计的。

思考一个问题：对于上面列出的各类缓冲区，为什么要为每条线程都分配专属的内存，而不是直接在共享内存中搞一块大的空间，然后提供给所有线程来操作呢？其实答案很简单，因为这些数据本身就是一条线程在执行SQL时产生的临时数据，其他线程压根不会去用到另一条线程的临时数据，所以这些临时数据没有必要被共享。

除开上述原因外，将这些缓冲区都放在线程本地内存中，还有一点最大的好处：能够提升多线程并发执行的性能！这句话怎么理解呢？很简单，如果把上述的各个缓冲区放在共享内存中，然后提供给线程存放执行时的临时数据，因为多线程的缘故，所以同一时刻、同一快内存有可能出现多条线程一起操作，那就会出现线程不安全的问题，想要解决就只能加锁将多线程串行化，这自然会在很大程度上影响性能！因此将这些存临时数据的缓冲区，设计在本地内存中才最合适。

不过也并非所有数据都适合放在线程的本地内存中，有一些多条线程之间都会访问的数据，如果再放到本地内存中，就会造成很大的冗余性，比如典型的索引根节点数据，每条线程都有可能会通过索引查询数据，因此每条线程都“缓存”一份放在自己的内存中，就会占用大量的内存空间，这样反而弊大于利。

下面再一起聊聊MySQL的共享内存区域，以及其中到底会存哪些数据。

1.3、MySQL共享内存区

先简单介绍一下上述给出的几个内容：

Key Buffer：MyISAM表的索引缓冲区，提升MyISAM表的索引读写速度。
Query Cache：查询缓存区，缓冲SQL的查询结果，提升热点SQL的数据检索效率。
Thread Cache：线程缓存区，存放工作线程运行期间，一些需要被共享的临时数据。
Table Cache：表数据文件的文件描述符缓存，提升数据表的打开效率。
Table Definition Cache：表结构文件的文件描述符缓存，提升结构表的打开效率。

上面的这几个线程共享区域还比较容易理解，对于最后两个文件描述符缓存，大家可能存在些许疑惑，这里可以先看一下《FD-文件描述符的定义》，文件描述符本质上就是一个指针，指向一个具体的数据。这里为何要在内存中存放表数据文件、表结构文件的FD缓存呢？主要是为了提升性能，先来看一个问题：

比如我现在想要操作zz_users表的数据，那首先是不是得找到这张表？但表的位置可能分布在磁盘的任何一处，总不能触发磁盘IO把整个磁盘检索一遍，然后确定表的位置吧？所以内存中直接设计了一个缓存区，专门缓存这些表数据文件的磁盘位置，要对某张表进行操作时，直接去文件描述符缓存中找，然后根据其中记录的地址，去磁盘中固定的位置上操作表数据。

表结构的文件描述符缓存，作用也是相同的，比如现在要增加一个索引，或者修改一个字段，也不会把磁盘全部扫描一遍，而是直接根据内存中的文件描述符，去操作磁盘中对应位置的表结构文件。

但是这两个文件描述符缓存，更多的是为MyISAM引擎设计的，关于具体原因稍后再说。

1.3.1、MySQL8.x为什么移除了查询缓存？

OK~，再简单聊一下QueryCahce查询缓存，这块的设计思想是非常好的，也就是利用热点探测技术，对于一些频繁执行的查询SQL，直接将结果缓存在内存中，之后再次来查询相同数据时，就无需走磁盘，而是直接从查询缓存中获取数据并返回。

听起来似乎还不错呀，好像确实能带来不小的性能提升呢？但实则很鸡肋，为啥？看个例子。

select * from zz_users where user_id=1;
select * from zz_users where user_id = 1;

比如上述这两条SQL语句，在我们看来是不是一样的？确实，都是在查询ID=1的用户数据，但奇葩的事情出现了，MySQL的查询缓存会把它当做两条不同的SQL，也就是假如上面的第一条SQL，其查询结果被放入到了缓存中，第二条SQL依旧无法命中这个缓存，会继续走表查询的形式获取数据，Why？

因为MySQL查询缓存是以SQL的哈希值来作为Key的，上面两条SQL虽然一样，但是后面的查询条件有细微差别：user_id=1、user_id = 1，也就是一条SQL有空格，一条没有。

由于这一点点细微差异，会导致两条SQL计算出的哈希值完全不同，因此无法命中缓存，是不是很鸡肋？还有多种情况：user_id =1、user_id= 1，空格处于的前后位置不同，也会导致缓存失效。

也正是由于方方面面的原因，所以查询缓存在MySQL8.0中被完全舍弃了，即移除掉了查询缓存区，各方面原因如下：

①缓存命中率低：几乎大部分SQL都无法从查询缓存中获得数据。
②占用内存高：将大量查询结果放入到内存中，会占用至少几百MB的内存。
③增加查询步骤：查询表之前会先查一次缓存，查询后会将结果放入缓存，额外多几步开销。
④缓存维护成本不小，需要LRU算法淘汰缓存，同时每次更新、插入、删除数据时，都要清空缓存中对应的数据。
⑤InnoDB引擎构建出的缓冲区中，也会类似的功能，因为与查询缓存也存在冲突。

因为上述一系列原因，再加上项目中一般都会使用Redis先做业务缓存，因此能来到MySQL的查询语句，几乎都是要从表中读数据的，所以查询缓存的地位就显得更加突兀，因此在高版本中就直接去掉了，毕竟弊大于利，带来的收益达不到设计时的预期。

1.4、存储引擎缓冲区

简单的讲明白线程共享区后，再来聊一聊存储引擎缓冲区，这块是本章重点，几乎任何存储引擎都会在启动时，向操作系统申请一块内存，用来作为缓冲区，每个引擎的缓冲区也并不相同，但有一点是共通的：即所有引擎的缓冲区，对于MySQL的工作线程而言，都是一块共享的内存区域。

现如今，MySQL众多存储引擎中，应用最为广泛的是InnoDB，所以我们就以InnoDB-Buffer Pool为例，在之前的MySQL章节中，我曾一度将其称之为「写入缓冲」，但要记住：BufferPool不仅仅只扮演「写入缓冲」的角色，其中主要包含了如下内容：

同样先简单介绍一下其中每个区域的作用：

Data Page：写入缓冲区，主要用来缓冲磁盘的表数据，将写操作转移到内存进行。
Index Page：索引缓冲页，对于所有已创建的索引根节点，都会放入到内存，提升索引效率。
Lock Space：锁空间，主要是存放所有创建出的锁对象，详情可参考《MySQL锁机制实现原理》。
Dict Info：数据字典，主要用来存储MySQL-InnoDB引擎自带的系统表。
redo_log_buffer：redo-log缓冲区，存放写SQL执行时写入的redo记录。
undo_log_buffer：undo-log缓冲区，存放写SQL执行时写入的undo记录。
Adaptivity Hash：自适应哈希索引，InnoDB会为热点索引页，创建相应的哈希索引。
Insert Buffer：写入缓冲区，对于insert的数据，会先放在这里，然后定期刷写磁盘。
Lru List：内存淘汰页列表，对于整个缓冲池的内存管理列表（后续细聊）。
Free List：空闲内存列表，这里面记录着目前未被使用的内存页。
Flush List：脏页内存列表，这里主要记录未落盘的数据。

一顿看下来，其实Buffer Pool中内容还真不少，但估摸着大家看上面的释义，难免有些懵，这点先不急，后续段落会详细拆解，在此处先对这些内容有些印象即可，现在先说说为何各大存储引擎都会设计一个缓冲池吧。

虽然MySQL是基于磁盘存储数据的，但总不能每次读写操作都走磁盘吧？这样绝对会导致资源开销极大，同时性能也极低，因此各引擎都在内存中设计了一个缓冲池，用来提升数据库整体的读写性能。

而InnoDB引擎，是尤为特殊的存在，几乎将所有的操作都放在了内存中完成，因此慢慢的，InnoDB代替了MyISAM，成为了MySQL默认的存储引擎，不过还有其他方面的因素导致的，具体原因在下章：《MySQL引擎篇》中细聊。

二、InnoDB的核心 - Buffer Pool

刚刚聊到过，InnoDB引擎几乎将所有操作都放在了内存中完成，这句话主要是跟它的Buffer Pool有关，但Buffer Pool到底会占用多大内存呢？这点可以通过show global variables like "%innodb_buffer_pool_size%";指令查询，如下：

show global variables like "%innodb_buffer_pool_size%";
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| innodb_buffer_pool_size | 44040192 |
+-------------------------+----------+
1 row in set (0.06 sec)

在MySQL5.6版本以下，默认大小为42MB，而MySQL5.6以后的版本中，默认大小为128MB，这块内存是MySQL启动时向OS申请的一块连续空间。当然，我们也可以手动调整innodb_buffer_pool_size参数来控制，一般建议设置为机器内存的60~80%。

接下来咱们先把Buffer Pool中每个区域的具体作用说明白，也就是这张图：

2.1、数据页（Data Page）

InnoDB引擎为了方便读取，会将磁盘中的数据划分为一个个的「页」，每个页的默认大小为16KB，以页作为内存和磁盘交互的基本单位，而InnoDB的缓冲池也会以页作为单位，也就意味着：当InnoDB拿到申请的连续内存后，会按照16KB的尺寸将整块空间，划分成一个个的缓冲页。

在MySQL运行之初，这些划分出的缓冲页，都属于空闲页，也就是未使用的内存，随着运行时长的慢慢增长，会将磁盘中的数据页，一点点的载入内存当中，因为磁盘中的表数据是以16KB作为单位划分的，而内存中的缓冲页也是这个大小，因此发生一次磁盘IO读到的数据（读一页磁盘数据），会放入到一个缓冲页中存储，而这些承载磁盘数据的缓冲页，就被称之为数据页，其过程如下：

当磁盘中的数据被载入到内存之后，带来的优势会极为明显：

读数据时：如果在数据页中有，则直接会从内存中读取数据并返回，没有再去磁盘检索数据。
写数据时：会先修改数据页的数据，修改后会标记相应的数据页，然后直接返回，再由后台线程去完成数据的落盘工作。

此时有没有发现：InnoDB的缓冲池，其实也具备「查询缓存」的功能~

不过MySQL会将哪些表数据放到缓冲池中呢？其实刚启动时里面并不会有数据，而是随着业务SQL的执行，一点点将磁盘中的数据加载进内存的，比如执行一条查询语句，因为最初内存中并没有加载数据页，因此会走磁盘检索数据，检索数据的过程中，不管此次IO读到的数据是不是目标数据，都会将它们放在内存中，而不是直接回收。

观察上述这个过程，这样做有什么好处呢？方便后续其他SQL要操作对应数据时，可以直接在内存中读到数据。

在条件允许，即内存充足的情况下，InnoDB会试图将磁盘中的所有表数据全部载入内存。

不过一般的机器，磁盘空间都会比内存要大出很多倍，所以当表数据较大时，也不可能无限制的载入，因而InnoDB会有一套完善的内存管理与淘汰机制，以此防止内存溢出风险（对于这点后续再详细阐述）。

2.2、索引缓冲页（Index Page）

上面讲到了，InnoDB会将部分乃至所有表数据载入内存，以此达到提升性能的目的，但不可能无限制载入，比如现在机器的内存为16GB，但磁盘中有30GB表数据，这显然无法放入进内存，所以无可避免的一点：在运行过程中，MySQL会走磁盘读数据。

比如一条查询语句要读的数据，在内存中没有相关的缓冲数据页，因此需要触发磁盘IO检索数据，但此时这条SQL可以命中索引，那会通过索引去查找数据，但问题来了！索引的根节点可能位于磁盘的任意位置，难道把磁盘的所有位置全部走一遍吗？这显然并不现实，所以InnoDB也会有对应的优化机制，即内存中也会缓冲索引页。

在MySQL启动时，就会将当前库中所有已存在的索引，其根节点放入到内存缓冲区中，因为索引的根节点只有16KB，因此就算目前库中就算创建了1000个索引，所有索引的根节点加起来占用的内存空间，也不过才15MB左右。将索引的根节点载入内存后，对于需要走索引查询的SQL，就会直接以相应的索引根节点为起始，然后去走索引查找数据，这样就避免了全盘查找索引根节点的这步操作。

Buffer Pool中有一块专门的区域：Index Page，专门用来存放载入的索引数据，存储这些数据的缓冲页，则被称之为索引页。随着运行时间的增长，也会将一些非根节点的索引页载入内存中，这是一种对于访问频率较高的索引页，专门推出的优化机制。

2.3、锁空间（Lock Space）

对于锁空间，相信认真看过《MySQL事务与锁原理篇》的小伙伴都不会陌生，咱们在其中讲锁机制的实现原理时，聊到过锁是基于事务实现，每个事务会生成自己的锁结构，而这些锁结构也同样需要空间来存储，而锁空间就是专门用来存储锁结构的一块内存区域。

但锁空间也不仅仅只会存储锁结构，还会存储一些并发事务的链表，例如死锁检测时需要的「事务等待链表、锁的信息链表」等。

锁空间一般都是有大小限制的，在《MySQL锁机制-锁粗化》中聊到过一种情况，当锁空间内存不足时，就会导致行锁粗化成表锁，以此来减少锁结构的数量，释放一定程度上的内存，但此时并发冲突就会变高！

2.4、数据字典（Dict Info）

对于数据字典估计大家很少有人接触过，毕竟这个是用来辅助InnoDB运行用的，咱们先思考一个问题，为啥我们可以通过SQL语句查询到库中的表信息、查询一张表的索引、约束等信息呢？如下：

-- 查询当前库中的所有表
show tables;
-- 查询一张表的全部索引
show index from `tableName`;

这些语句执行后都能查询出对应的信息，但这些信息咋来的呢？这首先跟MySQL的系统表有关，在InnoDB引擎中主要存在SYS_TABLES、SYS_COLUMNS、SYS_INDEXES、SYS_FIELDS这四张系统表，主要是用来维护用户定义的所有表的各种信息，如下：

SYS_TABLES：这张表中会存储所有引擎为InnoDB的表信息。
- ID：一张表的ID号。
- NAME：一张表的名称。
- N_COLS：一张表的字段数量。
- TYPE：一张表所使用的存储引擎、编码格式、压缩算法、排序规则等。
- SPACE：一张表所位于的表空间。
SYS_COLUMNS：这张表用来存储所有用户定义的表字段信息。
- TABLE_ID：表示一个字段属于那张表。
- POS：一个字段在一张表中属于第几列。
- NAME：一个字段的名称。
- MTYPE：一个字段的数据类型。
- PRTYPE：一个字段的精度值。
- LEN：一个字段的存储长度限制。
SYS_INDEXES：这张表用来存储所有InnoDB引擎表的索引信息。
- TABLE_ID：表示这个索引属于哪张表。
- ID：一个索引的ID号。
- NAME：一个索引的名称。
- N_FIELDS：一个索引由几个字段组成。
- TYPE：一个索引的类型，如唯一、联合、全文、主键索引等。
- SPACE：一个索引的数据所位于的表空间位置。
- PAGE_NO：这个索引对应的B+Tree根节点位置。
SYS_FIELDS：这张表用来存储所有索引的定义信息。
- INDEX_ID：当前这个索引字段属于哪个索引。
- POS：当前这个索引字段，位于索引的第几列。
- COL_NAME：当前索引字段的名称。

这四张表也被称为InnoDB的内部表，这四张表在载入内存前，位于.ibdata文件中，在MySQL启动时会开始加载，载入内存后就会放入到Dict Info这块区域，当利用show语句查询表的结构信息时，就会在字典信息中检索数据。

2.5、日志缓冲区（Log Buffer）

InnoDB的缓冲池中，主要存在两个日志缓冲区，即undo_log_buffer、redo_log_buffer，分别对应着撤销日志和重做日志，但对于日志缓冲区就不过多介绍了，在《MySQL日志篇》中咱们已经反复说到过，它俩的作用主要是用来提升日志记录的写入速度，因为日志文件在磁盘中，执行SQL时直接往磁盘写日志，其效率太低了，因此会先写缓冲区，再由后台线程去刷写日志。

2.6、自适应哈希索引（Adaptivity Hash）

自适应哈希索引又是一个比较有趣的技术点，这种技术可以算的上是一种AI技术，哈希算法查找数据的效率非常高，在没有哈希冲突的情况下复杂度为O(1)，而B+Tree检索数据的效率，取决于树的高度。建立索引时，只能选用一种数据结构来作为索引的底层结构：

如果选择哈希结构，虽然效率高，但数据是无序的，因此不方便做排序查询。
如果选择B+Tree结构，虽然有序，但查询的效率会受到树高的影响。

此时似乎陷入了两难的地步，两种结构各有优劣，但一般为了满足业务按序查询的需求，所以会折中选择B+Tree结构，虽然没有哈希索引那么快，但速度也还可以。

分析上述这个场景，明明选哈希结构的效率特别惊人，但就是不能用，这就好比你面前有一道绝世佳肴，但就不能吃一样，这显然令人十分难受。

而正是由于此原因，InnoDB创始人在研发时，就实现了一种名为自适应哈希索引的技术，在MySQL运行过程中，InnoDB引擎会对表上的索引做监控，如果某些数据经常走索引查询，那InnoDB就会为其建立一个哈希索引，以此来提升数据检索的效率，并且减少走B+Tree带来的开销，由于这种哈希索引是运行过程中，InnoDB根据B+Tree的索引查询次数来建立的，因此被称之为自适应哈希索引。

自适应哈希索引和普通哈希索引的区别在哪儿呢？普通哈希索引是在创建索引时将结构声明为Hash结构，这种索引会以索引字段的整表数据建立哈希，而自适应哈希索引是根据缓冲池的B+树构造而来，只会基于热点数据构建，因此建立的速度会非常快，毕竟无需对整表都建立哈希索引。

自适应哈希索引在InnoDB中是默认开启的，可以通过手动调整innodb_adaptive_hash_index参数来控制关闭，但一般尽量不要去关闭它，因为该技术能让MySQL的整体性能翻倍。

在MySQL8.0以下的版本中，如果同时删除一张大表的很多数据，有可能会因为自适应哈希索引的原因，造成线上MySQL出现抖动，不过该问题在MySQL8.x版本中已经被修复，但如若你的MySQL版本在此之下，那尽量不要在业务高峰期删除大量数据。

对于自适应哈希索引的使用情况，可以通过show engine innodb status \G;命令查看，但哈希索引由于自身特性的原因，因此也仅只能用于等值查询的场景，无法支持排序、范围查询。

2.7、写入缓冲区（Insert Buffer）

「Change Buufer写入缓冲」属于InnoDB的一大特性，其实「写入缓冲」在一开始被称之为「Insert Buffer插入缓冲」，也就是只对insert操作生效，到了MySQL5.5之后的版本中，才正式改为「写入缓冲」，对于insert、delete、update语句都可生效，那它的具体作用是干啥的呢？一起来简单的聊一聊。

结合前面聊过的「数据缓冲页」，咱们可以得知一点：如果要变更的数据页在缓冲区中存在，则会直接修改缓冲区中的数据页，然后标记一下变更过的数据页，但如果要操作的数据页并未被加载到缓冲区，那依旧会走磁盘去操作数据，走磁盘显然会影响性能，因此InnoDB就创造了一个「写入缓冲」。

以insert语句为例，不管在MySQL的任何版本中，执行一条插入语句之前，因为这条数据在磁盘中都不存在，因此缓冲区中自然也不可能会有对应的数据页，按照前面的说法，似乎必须走磁盘插入数据了对不？

「写入缓冲」出现的原因，就是为了解决此问题，当一条写入语句执行时，流程如下：

①判断要变更的数据页是否被载入到内存。
②如果内存中有对应的数据页，则直接变更缓冲区中的数据页，完成标记后则直接返回。
③如果内存中没有对应的数据页，则将要变更的数据放入到「写入缓冲」中，然后返回。

此时会发现，不管内存中是否存在相应的数据页，InnoDB都不会走磁盘写数据，而是直接在内存中完成所有操作，但是要注意：并不是所有的写入动作，都可以在内存中完成，「写入缓冲」是有限制的，如下：

插入的数据字段不能具备唯一约束或唯一索引。

为啥呢？因为如果存在唯一字段的表，在插入数据前必须要先判断表中是否存在相同值，一张表的数据不可能全部都载入数据，所以这个判断重复值的工作必须依赖磁盘中的表数据来完成，所以插入具备唯一性的数据时，就必须要走磁盘。

这里有小伙伴或许会疑惑了，那我表中会有一个主键呀，默认会存在一个主键索引，主键索引也是一种特殊的唯一索引，那不就意味着所有具备主键的表，都不能通过「写入缓冲」来插入数据呀？这点不一定，如果表的主键声明了是一个自增ID，那这个自增序列会由MySQL-Server自己来维护，因此ID会由MySQL来生成，是绝对不会出现重复值的，因此对于这种情况，会将要插入的数据放到「写入缓冲区」中。

那如果表中存在唯一索引、或者表的主键未声明是自增ID，难道插入数据时就不会用到这个「写入缓冲区」吗？答案是NO，依旧会用，为啥？先来回顾一下之前咱们讲过的《插入数据时索引的变化》，一条插入语句的执行过程如下：

①先向聚簇索引中，插入一条相应的行记录（数据）。
②对于非聚簇索引，都插入一个新的索引键，并将值指向聚簇索引中插入的主键值。

发现没有？插入数据时还需额外维护表中的次级索引，会为插入的新数据构建次级索引的索引键，并且将索引键插入到次级索引树当中，而这个过程就会用到「写入缓冲区」。

因为首先需要走一次磁盘，先插入行记录，插入完成后，假设表中存在三个非聚簇索引（次级索引），那难道再写三次磁盘维护次级索引吗？NO，对于不具备唯一性的索引，都会将要插入的索引键放在「写入缓冲区」。

对于修改、删除语句的执行，也是同理，那「写入缓冲区」中的数据究竟啥时候会真正写入到磁盘呢？

当一条SQL需要用到对应的索引键查询数据时，会触发后台线程执行刷盘工作。
当「写入缓冲区」内存空间不足时，会触发后台线程执行刷盘工作。
当距离上一次刷盘的时间，间隔达到一定程度（默认10s），会触发后台线程执行刷盘工作。
MySQL-Server正在关闭时，也会触发后台线程执行刷盘工作。

上述这四种情况，都会导致后台线程执行刷盘工作，从而将数据真正的落入磁盘中存储。

到这里就已经将InnoDB缓冲池中，运行期间会出现的东西都讲明白啦，但最开始咱们提过一点，缓冲池是有大小限制的，毕竟内存有限，因此也不可能让咱们无限制的使用，那InnoDB是如何管理缓冲池内存的呢？接下来一起聊聊这个话题。

三、InnoDB缓冲池的内存是如何管理的？

InnoDB虽然在启动时，会将连续的内存划分为一块块的缓冲页，但这仅是逻辑上的划分，本质上所有的缓冲页之间，也是连续的内存。但随着MySQL在线上运行的时间越来越长，自然会导致这片连续的缓冲页变得七零八落，如下：

当从磁盘加载一个数据页时，总不能将所有的缓冲页全部遍历一次，然后找到其中的空闲页放数据吧？这样难免有些影响性能，所以为了更好的管理缓冲池，InnoDB会为每个缓冲页创建一个控制块。

3.1、缓冲页的控制块是是个啥？

控制块是专门用于管理缓冲页而设计的一种结构，其中会包含：数据页所属的表空间、页号、缓冲页地址、链表节点指针等信息，所有的控制块都会放在缓冲池最前面，如下：

当然，控制块也会占用缓冲池的内存空间，InnoDB会为每一个缓冲页都分配一个对应的控制块，后续InnoDB可以基于控制块去管理每一块缓冲页。

3.2、空闲页的管理

首先来聊聊对于空闲缓冲页的管理，为了能够更快的找到缓冲池中的空闲页，InnoDB会以控制块作为节点，将所有空闲的缓冲页组成一个空闲链表，也就是之前的Free链表，示意图如下：

因为控制块对应着一个个的缓冲页，以控制块作为链表节点，也就等价于是由缓冲页组成的链表，在链表中会存在一个头结点，内部主要有三个值：

head：这是一根指针，指向空闲链表的第一个控制块。
tail：同样是一根指针，指向空闲链表的最后一个控制块。
count：这是一个数字，用来记录空闲链表的节点数量。

有了空闲链表后，会有什么好处呢？十分明显，当需要一块新的缓冲页存储磁盘数据时，不需要再去遍历所有缓冲页找一块空闲的出来了，而是直接找到空闲链表，根据空闲链表的指针，从中拿一块空闲缓冲页使用即可。

3.3、标记页的管理

咱们在前面提到过，当线程变更了内存中的数据页之后，会先对这个数据页做个标记，然后直接给客户端返回「执行成功」的响应。在这个过程中，被线程变更并标记过的数据页，则被称之为标记页，不过在有些地方也被称之为“脏页”。

对于内存中变更过的数据页，最终绝对是需要刷写到磁盘中的，前面也不止一次提到过，这个工作会由MySQL的后台线程完成，但问题又来了：当后台线程要刷盘时，它咋知道哪些数据页是变更过的呢？

有人也许会说，前面工作线程在执行完SQL之后，不是对数据页做了标记嘛？确实没错，但问题在于：缓冲池中的缓冲页那么多，后台线程难道去把所有缓冲页全部找一次，看看它有没有被标记嘛？

这样做确实可以，但还不够，因为每次刷盘都需遍历所有缓冲页，其过程的开销必然不小，比如刷盘时，缓冲池中就只有几个数据页发生了变更，为了刷写这几个页的数据就找一次所有页，这有点用迫击炮打鸟的意思在里面了。

因此为了后台线程刷盘时效率更高，InnoDB同样又创造了一个Flush链表，它的结构和Free链表一模一样，因此就不再画图了，两者的不同点在于：

Free链表：记录空闲缓冲页，为了使用时能更快的找到空闲缓冲页。
Flush链表：记录标记过的缓冲页，为了刷盘时能够更快的找到变更数据页。

当后台线程开始刷盘工作时，会直接找到Flush链表，然后直接将该链表中对应的缓冲页，其变更过的数据刷写到磁盘。

注意：标记页的刷盘时机与「写入缓冲」的刷盘时机相同，也包括「写入缓冲」也归属在Buffer Pool中，因此当「写入缓冲区」中有数据需要刷盘时，相应的缓冲页，同样会被加入Flush链表。

3.4、内存中的数据页是如何淘汰的？

Buffer Pool的内存空间是有限的，因此无法支撑所有数据源源不断的载入内存，所以InnoDB内部绝对有一套自己的淘汰机制，但先设想一个问题：所有数据都可以被淘汰吗？可以是可以，毕竟就算内存中的数据没了，磁盘中也会有数据，但是随机淘汰显然并不妥，我们希望做到是：那些频繁被访问的数据页可以长期驻留在内存中，一些很少被访问的数据页能够淘汰掉。

与Free空闲链表、Flush刷写链表相同，对于要可淘汰的数据页，也会被组合成一个LRU淘汰链表，但淘汰链表会由哪些缓冲页组成呢？首先对于空闲页和标记页是不会纳入淘汰范围内的，为啥？

空闲页：本身这些缓冲页都没有被使用，内存都是空白的，淘汰空闲页没有任何意义。
标记页：被标记过的缓冲页中，由于存在数据还未落盘，所以淘汰掉之后代表数据会丢失。

因此LRU链表是由已使用、但未曾变更过的缓冲页组成的，不过要注意：有些数据页会在Flush、LRU两个链表之间“跳动”：

当LRU链表中的一个数据页发生变更后，会从LRU链表转到Flush链表。
当标记页中的变更数据落盘后，此时标记页又会从Flush链表回到LRU链表。

有些地方会存在些许误区，也就是标记页（脏页）也会被放入LRU链表中，这显然是不对的，为啥？因为所有的链表都是由控制块作为节点构建的，而一个控制块中只有一根指针，也意味着一个控制块同时只能加入一个链表中，所以就不可能出现一个缓冲页，既处于LRU链表，又位于Flush链表中。

OK~，讲明白上面这点误区后，接着先说明一下淘汰的含义：淘汰是指将一个已使用的缓冲页，其中的所有数据清空，使其变为一个空闲页。

理解淘汰的含义后，再说说InnoDB的淘汰机制是怎么样的呢？很简单，和互联网大厂中的淘汰手段相同！即末尾淘汰机制。

3.4.1、末尾淘汰机制

互联网大厂并不像国企、编制这类铁饭碗，为了防止“蛀虫”产生，会不断的吸纳新鲜血液，有新人进，自然也就会有老人出，但Boss又不希望将哪些工作认真、技术过硬、成绩优异的精英淘汰掉，所以一个著名的手段：末尾淘汰机制就诞生了。

一般企业中都会有KPI绩效考核制度，一个员工的工作态度、工作成绩都会计算在KPI中，当企业的人员数量过于臃肿时，就会开启一轮淘汰环节，所有员工中会淘汰哪一部分人呢？也就是按员工的综合KPI来决定，一些长期保持吊车尾的员工，则会面临被“优化”的风险。

这种机制的好处在于：对于企业有用的精英们，永远都能够留下来，而对于一些成绩平平、工作态度不认真的员工，则会被淘汰出局，活生生一副弱肉强食的森林法则。

末尾淘汰机制虽然很残酷，但对于企业而言确实很管用，所以InnoDB中的淘汰机制亦是如此，先来聊聊最基本的末尾淘汰机制：

当一条线程来读写数据时，命中了缓冲区中的某个数据页，那就直接将该页挪到LRU链表最前面。
当未命中缓冲数据页时，需要走磁盘载入数据页，此时内存不够的情况下，会淘汰链表末尾的数据页。

从磁盘载入的数据会直接插入到LRU链表头部，也就是直接将其设置为链表的第一个节点。

这里也许有小伙伴会疑惑：似乎缓冲区中的数据页会一直频繁移动呐，这不会影响性能吗？答案是并不会，为啥呢？因为这里是链表结构而并非数组结构，将一个缓冲页移动到其他链表中，或将一个缓冲页移动到链表最前面，实际上只需要改一下指针即可，无需真正的触发数据挪动的工作。

OK~，举个简单的例子感受一下InnoDB的末尾淘汰机制！假设此时LRU链表由8个缓冲页组成，并且此时缓冲区空间已满，如下：

此时假设一条查询语句，命中了其中的第6个数据页，此时这个数据页会被挪到最前面：

此时又来了一条SQL，要操作的数据在缓冲区不存在，因此会从磁盘读取数据并载入内存，但因为目前缓冲区已经满了，所以需要淘汰一个缓冲页，用来存放载入的新数据，此时就会将末尾的数据页淘汰，如下：

上面这个过程列出了最简单的末尾淘汰机制，但这种方式会存在两个较为致命的问题：

①利用局部性原理预读失效时，会导致数据页常驻缓冲区。
②查询数据量过大时，会导致缓冲区中的热点数据全部被替换，导致缓冲池被“污染”。

3.4.2、预读失效问题

在讲《索引底层实现原理》时，曾详细的描述过磁盘IO的执行过程，在其中提到了一种利用“局部性原理预读数据”的机制，一般来说，当程序读取某块数据时，这块区域附近的数据也很有可能被读取，因为程序在存储数据时，都会将一个数据保存在一块连续的空间中，因此MySQL在读取数据时，默认会使用局部性思想预读数据，也就是读取一个数据时，默认会将其附近的16KB数据一次性全部载入内存。

刚刚的案例中讲到过，当数据载入内存后会分配一个缓冲页来存放，并且会将相应的数据页放在LRU链表的最前面，记住！这个数据页一共是有16KB数据的，也就意味着里面会有多行表数据，假设此时程序只读取了这页数据中的一行记录，对于其他数据并不需要读取，这也就是所谓的预读失效问题。

同时，MySQL读取数据时，除开会利用局部性原理将一整页数据载入内存外，InnoDB也有自己的预读机制，先来看一幅图：

当MySQL出现读取请求时，Server层会交由引擎层去处理，而引擎层又间接依赖于文件系统提供的I/O读取机制。文件系统中，为了保证数据的有序读取，所有请求会先放到请求队列中，等到数据准备就绪后，会将数据放入到响应队列中，最后再由相关进程（这里即是MySQL）的线程读走数据。

大家可以观察上述过程，假设zhuzi表中有500条数据，如果目前正在执行下面这条SQL：

select * from zhuzi where id >= 100;

意味着会去读400次数据（假设一次只能读一条），并且这个读取过程是线性同步的，即一条线程先读id=100的数据，再读101、102、103……，每读一条就要向文件系统发起一次读取请求，是不是很慢？答案是Yes，因此，InnoDB为了优化I/O读取的速率，推出了预读机制。

InnoDB在存储数据时，会以64个数据页作为一个extent，同时，InnoDB内部有两种预算策略：

①线性预读：当前extent中的数据页，被读取到一定数量时，触发预读直接提前读取下一个extent；
②随机预读：当前extent中的数据页，大部分被载入到内存时，会触发预读将extent剩下的数据页全部载入内存；

简单理解就是：每个数据页都被划分在一个个的extent里，一个extent容量为64，当select操作发生时，一个extent里被读取的数据页达到一定阈值后，会触发InnoDB的预读机制，将剩余的数据页、或下一个extent提前载入到内存中。那么，触发预读的阈值是多少呢？可以通过下述命令查询：

show variables like 'innodb_read_ahead_threshold';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| innodb_read_ahead_threshold | 56    |
+-----------------------------+-------+

答案是56，一个extent里的数据页，被读取56个以上，InnoDB就会提前将下一个extent所有数据页全部载入内存，当然，这是线性预读策略的做法，假设是随机预读，则会将剩下的8个数据页载入内存，不过随机预读策略不稳定，带来的弊端反而大于好处，因此默认是关闭状态（可以通过查询innodb_random_read_ahead参数验证）。

同时注意，InnoDB的预读动作，是由后台线程异步完成的，并不会影响执行业务SQL的线程，举个例子，t1线程在执行上面给出的语句，当触发预读机制的阈值后，InnoDB就会派一条后台线程：bg1，异步去将下一个extent中的64页数据载入内存。

好了，上面简单了解了InnoDB预读机制，那这种预读机制的好处是什么？在做范围查询时，InnoDB提前将需要的数据载入到了内存，后续需要用到时可以直接从内存获取，从而提升了查询效率。不过有利也有弊，预读机制能保证所有提前载入内存的数据页，都会被用上吗？答案是不能，而这些预读进内存、却没有用上的数据页，则被称为“预读失效的数据页”。

预读失效：即MySQL利用局部性原理预读载入的数据，或InnoDB预读机制提前载入的数据页，在接下来时间内并未被使用。
PS：InnoDB会统计预读的数据页、以及预读失效后被清理的数据页数量，对应的参数分别为innodb_buffer_pool_read_ahead、innodb_buffer_pool_read_ahead_evicted，感兴趣大家可以去查看一下。

大家想想啊，如果按照前面列举的那种末尾淘汰机制去载入数据，一页数据被载入后会放到链表的头部，那想要淘汰这个数据页还需要等很长很长一段时间，毕竟MySQL实际会划分出几千几万个缓冲页，把这个没用的数据页放在了最前面，也就意味着该数据页会占用缓冲页很长时间。

为了解决这个问题，InnoDB并未采用最基本的末尾淘汰算法，而是对其做了些许优化，会将整个LRU算法划分为old、young两个区域组成。

等等，old、young？这是不是很耳熟？熟悉JVM虚拟机的小伙伴应该知道，在JVM的内存模型中，也有类似的概念，所以其实到这里大家会发现，所有技术的底层大致都是共通的！

young、old两个区域在LRU链表中的占比，默认为63:37，你也可以通过innodb_old_blocks_pc这个参数，来手动调整old区在整个LRU链表中的占比。

默认不改的情况下，假设LRU链表中由100缓冲页构成，那么前63个属于young区，后37个属于old区，示意图如下：

LRU链表被划分为两个区域后，从磁盘中预读的数据页，就只需要加入到old区域的头部，当这个数据页被真正访问时，才会将其插入young区的头部。如果预读的这页在后续一直没有被访问，就会从old区域移除，从而不会影响young区域中的热点数据。

也就是说，在划分为两个区域后，young区域是用来存储真正的热点数据页，而old区则是用来存放有可能成为热点数据页的“候选人”，当需要淘汰缓冲页时，会优先淘汰old区中的数据页，毕竟young区中留下的都是久经考验的精英！

3.4.3、缓冲池污染问题

InnoDB将LRU链表划分为两个区域后，改善了预读失效带来的问题，但还不够，因为还有可能会出现缓冲池污染的问题，这又是啥意思呢？

此时假设一条线程在执行SQL语句，目前是需要查询一张百万级别的所有表数据，由于Buffer Pool空间有限，所以如果按照原本的淘汰规则来清理内存，这次查询过程可能会导致Buffer Pool里面的所有热点数据全部被换出。等这次查询结束后，内存中只剩下了这次查询载入的数据页，当有线程访问原本哪些热点数据时，由于缓冲区中的数据页被换出了，因此就会产生大量的磁盘IO。

上述这个过程，则被称之为Buffer Pool污染问题，但要注意：并不是需要查询大量结果才会导致这个问题出现，而是当扫描的数据过多时，都会引发此问题，比如典型的对大表执行了全表扫描，因为在扫描的过程，会不断从磁盘载入新的数据页放在内存中。

InnoDB为了解决该问题，又引入了一种新的技术，名为young区晋升限制，是不是有点耳熟？在JVM中，为了防止新生代过早晋升年老代，从而频繁触发FullGC的问题，在设计时也有晋升条件限制，默认情况下，一个对象只有达到了15岁之后，才能从新生代晋升年老代，毕竟能够熬过16轮新生代GC的对象，也绝对不会无缘无故突然挂掉。

而InnoDB中的young区晋升限制，同样是这个原理，毕竟上面的全表扫描案例中，很多数据页只会被访问一次，但是由于需要访问它，所以才被载入了内存，最终导致old区放不下，从而导致了young区的热点数据被替换。

而加入了young区的晋升限制后，就能有效避免这种访问一次的数据页过早进入young区，InnoDB是怎么做的呢？其实很简单，就是加了一个停留时间的限制，如果一个数据页想从old区晋升到young区，必须要在old区中存活一定时间，这个时间默认为1s/1000ms，也可以通过参数innodb_old_blocks_time调整。

思考一下，由于存在这个时间限制，所以old区的数据页，想要进入young区，就必须达成两个条件：
①在old区中停留的时间超过了1000ms。
②在old区中，一秒后有线程再次访问了这个数据页。

上面的第一条还比较容易理解，但第二条估计有些懵，啥意思啊？其实很简单，结合前面的淘汰算法：一个刚被载入的数据页，会先放到old区的头部，当该数据页被二次访问后才会挪到young区的头部。

那为啥又要等到一秒之后再次访问了才行呢？因为如果一个数据页被载入内存后，必须要先能撑住1s才行！

OK~，通过这种晋升限制的方式，就能完美的解决全表扫描引起的缓冲池污染问题，这也是InnoDB最终的淘汰机制，当一个缓冲页的数据被淘汰后，也就是一个缓冲页的数据被清空后，会将其再次加入到Free空闲链表中等待分配。

四、MySQL内存篇总结

经过上述一系列的分析后，咱们就将MySQL内存方面的知识理清楚了，尤其是关于InnoDB的缓冲池，会发现和我说的一样：InnoDB引擎几乎将所有的操作都放在了内存中进行，比如写日志、写数据、查数据等，只有逼不得已的情况下，才会走磁盘读写数据。

假设你部署MySQL的机器内存足够大，并且为Buffer Pool分配的内存空间也足够大，比如机器的内存有128GB，此时为Buffer Pool分配了100GB，而整个库的所有表数据加起来仅有80GB，此时要记住！InnoDB几乎会将所有的表数据全部载入内存，后续所有的读写操作都会基于内存+后台线程刷盘的方式进行。

到这里大家会发现，虽然InnoDB是一款基于磁盘研发的存储引擎，但它几乎将内存的使用开发到了极致，能在内存完成的就压根不会走磁盘，在最大程度上提升MySQL的整体性能。

OK~，最后稍微总结一下InnoDB内存管理这块的内容，InnoDB采用三个链表结构来管理所有的缓冲页：

Free链表：统一管理、分配所有未使用的缓冲页。
Flush链表：统一管理、刷写所有被标记过的缓冲页。
Lru链表：统一管理、淘汰所有已使用、未变更过的缓冲页。

在内存的淘汰机制方面，InnoDB基于末尾淘汰机制做了两点改善：

①将Lru链表划分为了young、old两个分区，用来解决预读失效导致的内存占用问题。
②引入了young区的晋升限制，解决了全表扫描时，young区的热点数据页被换出的问题。

至此，《MySQL内存篇》就告一段落啦~，在本篇中几乎讲到了MySQL、InnoDB内存使用的方方面面，当然，其他的存储引擎涉及不是太深，因此并为做过多的分析与讲解，大家对其他引擎的缓冲区感兴趣，也可以自行研究。

(十二)MySQL之内存篇：深入探寻数据库内存与Buffer Pool的奥妙！

引言

一、结合MySQL架构聊一聊它的内存

1.1、MySQL Server - 工作组件

1.2、工作线程的本地内存

1.3、MySQL共享内存区

1.3.1、MySQL8.x为什么移除了查询缓存？

1.4、存储引擎缓冲区

二、InnoDB的核心 - Buffer Pool

2.1、数据页（Data Page）

2.2、索引缓冲页（Index Page）

2.3、锁空间（Lock Space）

2.4、数据字典（Dict Info）

2.5、日志缓冲区（Log Buffer）

2.6、自适应哈希索引（Adaptivity Hash）

2.7、写入缓冲区（Insert Buffer）

三、InnoDB缓冲池的内存是如何管理的？

3.1、缓冲页的控制块是是个啥？

3.2、空闲页的管理

3.3、标记页的管理

3.4、内存中的数据页是如何淘汰的？

3.4.1、末尾淘汰机制

3.4.2、预读失效问题

3.4.3、缓冲池污染问题

四、MySQL内存篇总结

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

(十二)MySQL之内存篇：深入探寻数据库内存与Buffer Pool的奥妙！

引言

一、结合MySQL架构聊一聊它的内存

1.1、MySQL Server - 工作组件

1.2、工作线程的本地内存

1.3、MySQL共享内存区

1.3.1、MySQL8.x为什么移除了查询缓存？

1.4、存储引擎缓冲区

二、InnoDB的核心 - Buffer Pool

2.1、数据页（Data Page）

2.2、索引缓冲页（Index Page）

2.3、锁空间（Lock Space）

2.4、数据字典（Dict Info）

2.5、日志缓冲区（Log Buffer）

2.6、自适应哈希索引（Adaptivity Hash）

2.7、写入缓冲区（Insert Buffer）

三、InnoDB缓冲池的内存是如何管理的？

3.1、缓冲页的控制块是是个啥？

3.2、空闲页的管理

3.3、标记页的管理

3.4、内存中的数据页是如何淘汰的？

3.4.1、末尾淘汰机制

3.4.2、预读失效问题

3.4.3、缓冲池污染问题

四、MySQL内存篇总结

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像