在前几篇文章中我们深入磁盘解剖了表空间、页、行的物理结构。然而InnoDB 之所以能支撑高并发 OLTP 场景绝不仅仅是把数据规整地写在磁盘上——它有一整套精细的内存管理机制将“热数据”留在内存中将“随机写”优化为“顺序写”从而大幅提升性能。本文将聚焦 InnoDB 的三大核心内存结构Buffer Pool缓冲池缓存页减少磁盘 I/OChange Buffer变更缓冲优化二级索引的非顺序写入Log Buffer日志缓冲将 Redo Log 先存在内存再刷盘提升事务吞吐同时我们还会了解自适应哈希索引Adaptive Hash Index的作用并学习如何监控这些内存区域的使用状况。读完本文你将彻底理解为什么 InnoDB 能够“快”并能通过调整内存参数来优化自己的数据库。1. Buffer Pool —— InnoDB 的心脏1.1 为什么需要 Buffer Pool磁盘 I/O 是数据库最大的性能瓶颈。每次读写都访问磁盘性能将惨不忍睹。Buffer Pool 是一块巨大的内存区域用于缓存数据页、索引页。绝大多数读操作都直接从 Buffer Pool 返回写操作也是先修改内存中的页变成“脏页”再由后台线程异步刷盘。默认情况下Buffer Pool 占服务器物理内存的 75%~80%由innodb_buffer_pool_size控制它是 InnoDB 最重要的性能参数。如果设置过小就会频繁发生“页淘汰”导致磁盘 I/O 飙升过大则可能导致操作系统内存不足。查看当前大小SELECTinnodb_buffer_pool_size;1.2 页管理与 LRU 变体Buffer Pool 以**页Page16KB**为基本单位。当它被占满时需要淘汰一些不常用的页来腾出空间。经典算法是LRU最近最少使用但直接照搬会有一个严重问题一次全表扫描会读入大量新页把真正的热数据挤出 Buffer Pool这种现象叫缓冲池污染。InnoDB 使用LRU 变体来解决这个问题将 LRU 链表分为两个子链表靠近头部的是新生代New Sublist / Young Area靠近尾部的是老生代Old Sublist / Old Area。新读入的页首先插入到老生代的头部而不是整个 LRU 的头部。如果这个页在老生代中停留超过一定时间innodb_old_blocks_time默认 1000ms后被再次访问才被提升到新生代头部。这样全表扫描中短暂使用的页会在老生代中被迅速淘汰不会污染新生代中的热数据。关键参数innodb_old_blocks_pct老生代占整个 LRU 链表的百分比默认 37即 3/8。innodb_old_blocks_time页从老生代晋升新生代所需的“存活时间”毫秒。1.3 脏页与刷盘在 Buffer Pool 中被修改但尚未写入磁盘的页称为脏页Dirty Page。脏页最终必须写回磁盘这由后台线程完成而不是每次修改都立即刷盘Write-Ahead Logging 机制Redo Log 会先持久化。脏页的刷盘由innodb_max_dirty_pages_pct等参数控制。如果脏页比例过高会触发“同步刷盘”瞬间大量 I/O 导致性能抖动。2. Change Buffer —— 二级索引的写入优化2.1 二级索引写入的痛点假设一张表有多个二级索引非主键索引每次INSERT时除了更新聚簇索引还必须更新所有二级索引。如果二级索引页恰好不在 Buffer Pool 中这种情况在随机插入时非常常见就需要先从磁盘读取该页随机 I/O再修改——这会严重拖慢写入性能。2.2 Change Buffer 的工作原理Change Buffer以前叫 Insert Buffer就是解决这个问题的缓存。它是一块内存区域专门暂存对不在 Buffer Pool 中的二级索引页的变更操作INSERT、UPDATE、DELETE 的标记等。当执行一条插入语句时如果二级索引的目标页不在 Buffer Pool 中InnoDB 不会立即去磁盘加载它而是把这次变更记录到 Change Buffer 中。在后续某个时机如该页被读入 Buffer Pool 时或后台合并线程执行时再把 Change Buffer 中缓存的变更合并到真正的索引页中。这个操作叫merge。这样就将多次随机读/写合并为一次顺序操作极大提升写入吞吐。2.3 适用场景与限制最适合写多读少且二级索引列的值比较离散随机插入的场景如日志表、订单表。不适合表本身没有二级索引Change Buffer 无用。数据库服务器即将关闭时未合并的变更也会丢失实际上会在关闭前强制 merge。如果二级索引页很快就会被读取那么 Change Buffer 的优势就会打折扣因为迟早要 merge。相关参数innodb_change_buffer_max_sizeChange Buffer 占 Buffer Pool 的最大百分比默认 25。innodb_change_buffering控制开启哪些操作的缓冲all / none / inserts / deletes 等。3. Adaptive Hash Index —— 让热点查询更快InnoDB 默认使用BTree索引查找效率为 O(log n)。如果某些查询频繁地按照相同条件访问相同的行InnoDB 可以自动在内存中为这些“热点”建立哈希索引使等值查询直接变为 O(1)。这就是自适应哈希索引Adaptive Hash Index, AHI。AHI 完全由 InnoDB自动管理和观察你无法手动创建或指定。它只对等值查询WHERE col value有效对范围查询无效。当发现某段索引模式被频繁访问InnoDB 就会在 AH I 中建立对应的哈希项。可以通过SHOW ENGINE INNODB STATUS查看 AHI 的使用率和命中情况。如果发现命中率很低或者 CPU 使用异常高可以考虑关闭 AHIinnodb_adaptive_hash_indexOFF因为维护哈希表也有开销。4. Log Buffer —— 事务日志的暂存区我们在后续文章会详细学习 Redo Log这里先看它在内存中的“前哨站”——Log Buffer。当事务修改数据时首先会在内存中生成Redo 日志记录写入Log Buffer大小由innodb_log_buffer_size控制默认 16MB。随后这些日志记录会在以下时机被刷新到磁盘Redo Log 文件事务提交COMMITLog Buffer 空间不足脏页刷盘前Write-Ahead Logging 要求日志必须先于数据落盘后台主线程定期刷新大的 Log Buffer 可以减少对磁盘 Redo Log 文件的写入次数特别适合大事务如批量 INSERT场景。但如果事务很小默认 16MB 已经足够。查看SHOWVARIABLESLIKEinnodb_log_buffer_size;5. 监控内存使用状况5.1 总体概览最权威的方式是查看SHOW ENGINE INNODB STATUS\G的BUFFER POOL AND MEMORY部分---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 137428992; Dictionary memory allocated 307504 Buffer pool size 8191 Free buffers 1024 Database pages 7167 Old database pages 2648 Modified db pages 0 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 8, not young 0 0.00 youngs/s, 0.00 non-youngs/s Pages read 6917, created 250, written 124 0.00 reads/s, 0.00 creates/s, 0.00 writes/s ...关键字段解读Free buffers空闲页数量过少说明 Buffer Pool 压力大。Database pages当前缓存的数据页总数 Buffer pool size - Free buffers。Modified db pages脏页数量太多时需要增加刷盘速度或扩大 Buffer Pool。Pages read / created / written累积读/创建/写页数。youngs/s页从老生代晋升新生代的速率反映了热数据的访问模式。5.2 INFORMATION_SCHEMA 表更灵活的监控通过INFORMATION_SCHEMA实现INNODB_BUFFER_POOL_STATSBuffer Pool 整体统计。INNODB_BUFFER_PAGE_LRU每个页的 LRU 位置信息谨慎使用数据量大时查询本身消耗较大。INNODB_METRICS提供了大量计数器如buffer_pool_reads物理读、buffer_pool_read_requests逻辑读等可以计算缓冲命中率。计算缓冲命中率SELECT(1-(SUM(buffer_pool_reads)/SUM(buffer_pool_read_requests)))*100AScache_hit_rateFROMinformation_schema.innodb_metricsWHEREnameIN(buffer_pool_reads,buffer_pool_read_requests);通常命中率应接近 100%。如果低于 99%考虑增大innodb_buffer_pool_size。6. 实战调整缓冲池并观察效果我们来做一个简单实验先缩小 Buffer Pool观察查询变慢再恢复大小验证缓冲的威力。6.1 创建测试表CREATETABLEbp_test(idINTPRIMARYKEYAUTO_INCREMENT,dataVARCHAR(200))ENGINEInnoDB;-- 插入 20 万行数据可使用递归 CTE耐心等待INSERTINTObp_test(data)SELECTCONCAT(data_,LPAD(n,7,0))FROM(WITHRECURSIVE seq(n)AS(SELECT1UNIONALLSELECTn1FROMseqWHEREn200000)SELECTnFROMseq)nums;6.2 缩小 Buffer Pool 并测试查询暂时将 Buffer Pool 改小会话级不可设需要全局修改开发环境可以重启后设——若你无法改全局可观察已有监控。假设你设置innodb_buffer_pool_size 128M重启 MySQL。执行一次可能触发大量物理读的查询SELECTCOUNT(*)FROMbp_testWHEREdataLIKE%999%;先用EXPLAIN看下应该是全表扫描。用SHOW ENGINE INNODB STATUS观察物理读增长。6.3 扩大 Buffer Pool将innodb_buffer_pool_size调大到物理内存的 50%如 512M 或 1G重启 MySQL。再次执行同样的查询可能已经在内存中会很快观察逻辑读和物理读的比例。清理DROPTABLEbp_test;注意调整 Buffer Pool 大小在生产环境需谨慎尤其要关注操作系统剩余内存避免引发 OOM。7. 小结InnoDB 的内存架构是高性能的基石Buffer Pool缓存数据页使用改良 LRU 防止污染脏页由后台线程刷盘。它是 InnoDB 最重要的内存结构。Change Buffer暂存对不在 Buffer Pool 中的二级索引页的修改将随机 I/O 转化为批量合并适合写多读少的二级索引场景。Adaptive Hash Index自动为热点页建立哈希索引加速等值查询。Log BufferRedo Log 的内存暂存区事务提交时写入避免频繁小量磁盘 I/O。监控通过SHOW ENGINE INNODB STATUS和INFORMATION_SCHEMA查看内存使用重点关注缓冲命中率、脏页比例、空闲页数。理解这些内存组件是后续深入 Redo/Undo 日志、崩溃恢复和性能优化的基础。下一篇我们将目光转向磁盘结构与关键日志详细剖析 Redo Log、Undo Log 和双写缓冲区看它们如何联手保证数据的持久性和一致性。思考题为什么 InnoDB 不直接用标准 LRU而要分新生代和老生代如果一张表只有主键没有二级索引Change Buffer 还有作用吗尝试在你自己的数据库中查询INNODB_BUFFER_POOL_STATS计算当前缓冲命中率。参考资料MySQL 8.0 Reference Manual - InnoDB Buffer PoolMySQL 8.0 Reference Manual - InnoDB Change BufferMySQL 8.0 Reference Manual - Adaptive Hash Index
InnoDB 内存架构：Buffer Pool、Change Buffer 与 Log Buffer
发布时间：2026/6/8 13:16:45
在前几篇文章中我们深入磁盘解剖了表空间、页、行的物理结构。然而InnoDB 之所以能支撑高并发 OLTP 场景绝不仅仅是把数据规整地写在磁盘上——它有一整套精细的内存管理机制将“热数据”留在内存中将“随机写”优化为“顺序写”从而大幅提升性能。本文将聚焦 InnoDB 的三大核心内存结构Buffer Pool缓冲池缓存页减少磁盘 I/OChange Buffer变更缓冲优化二级索引的非顺序写入Log Buffer日志缓冲将 Redo Log 先存在内存再刷盘提升事务吞吐同时我们还会了解自适应哈希索引Adaptive Hash Index的作用并学习如何监控这些内存区域的使用状况。读完本文你将彻底理解为什么 InnoDB 能够“快”并能通过调整内存参数来优化自己的数据库。1. Buffer Pool —— InnoDB 的心脏1.1 为什么需要 Buffer Pool磁盘 I/O 是数据库最大的性能瓶颈。每次读写都访问磁盘性能将惨不忍睹。Buffer Pool 是一块巨大的内存区域用于缓存数据页、索引页。绝大多数读操作都直接从 Buffer Pool 返回写操作也是先修改内存中的页变成“脏页”再由后台线程异步刷盘。默认情况下Buffer Pool 占服务器物理内存的 75%~80%由innodb_buffer_pool_size控制它是 InnoDB 最重要的性能参数。如果设置过小就会频繁发生“页淘汰”导致磁盘 I/O 飙升过大则可能导致操作系统内存不足。查看当前大小SELECTinnodb_buffer_pool_size;1.2 页管理与 LRU 变体Buffer Pool 以**页Page16KB**为基本单位。当它被占满时需要淘汰一些不常用的页来腾出空间。经典算法是LRU最近最少使用但直接照搬会有一个严重问题一次全表扫描会读入大量新页把真正的热数据挤出 Buffer Pool这种现象叫缓冲池污染。InnoDB 使用LRU 变体来解决这个问题将 LRU 链表分为两个子链表靠近头部的是新生代New Sublist / Young Area靠近尾部的是老生代Old Sublist / Old Area。新读入的页首先插入到老生代的头部而不是整个 LRU 的头部。如果这个页在老生代中停留超过一定时间innodb_old_blocks_time默认 1000ms后被再次访问才被提升到新生代头部。这样全表扫描中短暂使用的页会在老生代中被迅速淘汰不会污染新生代中的热数据。关键参数innodb_old_blocks_pct老生代占整个 LRU 链表的百分比默认 37即 3/8。innodb_old_blocks_time页从老生代晋升新生代所需的“存活时间”毫秒。1.3 脏页与刷盘在 Buffer Pool 中被修改但尚未写入磁盘的页称为脏页Dirty Page。脏页最终必须写回磁盘这由后台线程完成而不是每次修改都立即刷盘Write-Ahead Logging 机制Redo Log 会先持久化。脏页的刷盘由innodb_max_dirty_pages_pct等参数控制。如果脏页比例过高会触发“同步刷盘”瞬间大量 I/O 导致性能抖动。2. Change Buffer —— 二级索引的写入优化2.1 二级索引写入的痛点假设一张表有多个二级索引非主键索引每次INSERT时除了更新聚簇索引还必须更新所有二级索引。如果二级索引页恰好不在 Buffer Pool 中这种情况在随机插入时非常常见就需要先从磁盘读取该页随机 I/O再修改——这会严重拖慢写入性能。2.2 Change Buffer 的工作原理Change Buffer以前叫 Insert Buffer就是解决这个问题的缓存。它是一块内存区域专门暂存对不在 Buffer Pool 中的二级索引页的变更操作INSERT、UPDATE、DELETE 的标记等。当执行一条插入语句时如果二级索引的目标页不在 Buffer Pool 中InnoDB 不会立即去磁盘加载它而是把这次变更记录到 Change Buffer 中。在后续某个时机如该页被读入 Buffer Pool 时或后台合并线程执行时再把 Change Buffer 中缓存的变更合并到真正的索引页中。这个操作叫merge。这样就将多次随机读/写合并为一次顺序操作极大提升写入吞吐。2.3 适用场景与限制最适合写多读少且二级索引列的值比较离散随机插入的场景如日志表、订单表。不适合表本身没有二级索引Change Buffer 无用。数据库服务器即将关闭时未合并的变更也会丢失实际上会在关闭前强制 merge。如果二级索引页很快就会被读取那么 Change Buffer 的优势就会打折扣因为迟早要 merge。相关参数innodb_change_buffer_max_sizeChange Buffer 占 Buffer Pool 的最大百分比默认 25。innodb_change_buffering控制开启哪些操作的缓冲all / none / inserts / deletes 等。3. Adaptive Hash Index —— 让热点查询更快InnoDB 默认使用BTree索引查找效率为 O(log n)。如果某些查询频繁地按照相同条件访问相同的行InnoDB 可以自动在内存中为这些“热点”建立哈希索引使等值查询直接变为 O(1)。这就是自适应哈希索引Adaptive Hash Index, AHI。AHI 完全由 InnoDB自动管理和观察你无法手动创建或指定。它只对等值查询WHERE col value有效对范围查询无效。当发现某段索引模式被频繁访问InnoDB 就会在 AH I 中建立对应的哈希项。可以通过SHOW ENGINE INNODB STATUS查看 AHI 的使用率和命中情况。如果发现命中率很低或者 CPU 使用异常高可以考虑关闭 AHIinnodb_adaptive_hash_indexOFF因为维护哈希表也有开销。4. Log Buffer —— 事务日志的暂存区我们在后续文章会详细学习 Redo Log这里先看它在内存中的“前哨站”——Log Buffer。当事务修改数据时首先会在内存中生成Redo 日志记录写入Log Buffer大小由innodb_log_buffer_size控制默认 16MB。随后这些日志记录会在以下时机被刷新到磁盘Redo Log 文件事务提交COMMITLog Buffer 空间不足脏页刷盘前Write-Ahead Logging 要求日志必须先于数据落盘后台主线程定期刷新大的 Log Buffer 可以减少对磁盘 Redo Log 文件的写入次数特别适合大事务如批量 INSERT场景。但如果事务很小默认 16MB 已经足够。查看SHOWVARIABLESLIKEinnodb_log_buffer_size;5. 监控内存使用状况5.1 总体概览最权威的方式是查看SHOW ENGINE INNODB STATUS\G的BUFFER POOL AND MEMORY部分---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 137428992; Dictionary memory allocated 307504 Buffer pool size 8191 Free buffers 1024 Database pages 7167 Old database pages 2648 Modified db pages 0 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 8, not young 0 0.00 youngs/s, 0.00 non-youngs/s Pages read 6917, created 250, written 124 0.00 reads/s, 0.00 creates/s, 0.00 writes/s ...关键字段解读Free buffers空闲页数量过少说明 Buffer Pool 压力大。Database pages当前缓存的数据页总数 Buffer pool size - Free buffers。Modified db pages脏页数量太多时需要增加刷盘速度或扩大 Buffer Pool。Pages read / created / written累积读/创建/写页数。youngs/s页从老生代晋升新生代的速率反映了热数据的访问模式。5.2 INFORMATION_SCHEMA 表更灵活的监控通过INFORMATION_SCHEMA实现INNODB_BUFFER_POOL_STATSBuffer Pool 整体统计。INNODB_BUFFER_PAGE_LRU每个页的 LRU 位置信息谨慎使用数据量大时查询本身消耗较大。INNODB_METRICS提供了大量计数器如buffer_pool_reads物理读、buffer_pool_read_requests逻辑读等可以计算缓冲命中率。计算缓冲命中率SELECT(1-(SUM(buffer_pool_reads)/SUM(buffer_pool_read_requests)))*100AScache_hit_rateFROMinformation_schema.innodb_metricsWHEREnameIN(buffer_pool_reads,buffer_pool_read_requests);通常命中率应接近 100%。如果低于 99%考虑增大innodb_buffer_pool_size。6. 实战调整缓冲池并观察效果我们来做一个简单实验先缩小 Buffer Pool观察查询变慢再恢复大小验证缓冲的威力。6.1 创建测试表CREATETABLEbp_test(idINTPRIMARYKEYAUTO_INCREMENT,dataVARCHAR(200))ENGINEInnoDB;-- 插入 20 万行数据可使用递归 CTE耐心等待INSERTINTObp_test(data)SELECTCONCAT(data_,LPAD(n,7,0))FROM(WITHRECURSIVE seq(n)AS(SELECT1UNIONALLSELECTn1FROMseqWHEREn200000)SELECTnFROMseq)nums;6.2 缩小 Buffer Pool 并测试查询暂时将 Buffer Pool 改小会话级不可设需要全局修改开发环境可以重启后设——若你无法改全局可观察已有监控。假设你设置innodb_buffer_pool_size 128M重启 MySQL。执行一次可能触发大量物理读的查询SELECTCOUNT(*)FROMbp_testWHEREdataLIKE%999%;先用EXPLAIN看下应该是全表扫描。用SHOW ENGINE INNODB STATUS观察物理读增长。6.3 扩大 Buffer Pool将innodb_buffer_pool_size调大到物理内存的 50%如 512M 或 1G重启 MySQL。再次执行同样的查询可能已经在内存中会很快观察逻辑读和物理读的比例。清理DROPTABLEbp_test;注意调整 Buffer Pool 大小在生产环境需谨慎尤其要关注操作系统剩余内存避免引发 OOM。7. 小结InnoDB 的内存架构是高性能的基石Buffer Pool缓存数据页使用改良 LRU 防止污染脏页由后台线程刷盘。它是 InnoDB 最重要的内存结构。Change Buffer暂存对不在 Buffer Pool 中的二级索引页的修改将随机 I/O 转化为批量合并适合写多读少的二级索引场景。Adaptive Hash Index自动为热点页建立哈希索引加速等值查询。Log BufferRedo Log 的内存暂存区事务提交时写入避免频繁小量磁盘 I/O。监控通过SHOW ENGINE INNODB STATUS和INFORMATION_SCHEMA查看内存使用重点关注缓冲命中率、脏页比例、空闲页数。理解这些内存组件是后续深入 Redo/Undo 日志、崩溃恢复和性能优化的基础。下一篇我们将目光转向磁盘结构与关键日志详细剖析 Redo Log、Undo Log 和双写缓冲区看它们如何联手保证数据的持久性和一致性。思考题为什么 InnoDB 不直接用标准 LRU而要分新生代和老生代如果一张表只有主键没有二级索引Change Buffer 还有作用吗尝试在你自己的数据库中查询INNODB_BUFFER_POOL_STATS计算当前缓冲命中率。参考资料MySQL 8.0 Reference Manual - InnoDB Buffer PoolMySQL 8.0 Reference Manual - InnoDB Change BufferMySQL 8.0 Reference Manual - Adaptive Hash Index
