innodb buffer pool

最新推荐文章于 2025-12-20 14:42:23 发布
原创 最新推荐文章于 2025-12-20 14:42:23 发布 · 243 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #算法

文章详细描述了InnoDB数据库的缓冲池如何使用LRU算法管理和优化内存，包括页链表结构、新旧子列表策略、预读策略以及针对空闲页和脏页的内存管理方法。特别提到innodb_old_blocks_time参数对减少预读问题的影响。

buffer pool是主存中的一个区域，InnoDB 在访问时缓存表和索引数据。缓冲池允许直接从内存访问频繁使用的数据，这加快了处理速度。在专用服务器上，高达80% 的物理内存通常分配给缓冲池。为了提高大容量读取操作的效率，将缓冲池划分为可能包含多行的页。为了提高缓存管理的效率，缓冲池被实现为页链表; 使用最近使用次数最少(LRU)算法的一个变体，很少使用的数据被老化到缓存之外。

buffer pool LRU

innodb buffer pool LRU在一个新页加入的时候会将最近最少使用的页驱逐出去，并将新页加入到链表中间。中点插入策略将链表看作两个子链表

  • 在new sublist的head是最近访问过的
  • 在old sublist的tail是最近最少访问过的

在这里插入图片描述

在该算法中定义最频繁访问的页在new sublist，old sublist则是访问不频繁的页，等待被淘汰

  1. 最初访问的页（用户发起的操作或者预读）将会插入到两个sublist的中点。也即new sublist尾部，old sublist头部

  2. 访问old sublist的页将会使之移动到new sublist的head

    如果由于用户发起的操作需要读取该页，则立即进行第一次访问，并使该页更新。如果由于预读操作而读取了该页，则第一次访问不会立即发生，并且可能在驱逐该页之前根本不会发生。

  3. 当数据库运行时，缓冲池中未被访问的页面会向列表尾部移动，从而“老化”。new sublist中的页面都会随着其他页面的更新而老化。old sublist中的页面也会随着页面在中点插入而老化。最终，未使用的页面到达old sublist的尾部并被驱逐。

默认情况下，查询读取的页面会立即移动到新的子列表中，这意味着它们在缓冲池中停留的时间更长。例如，对于mysqldump操作或不带WHERE子句的SELECT语句执行的表扫描，可能会将大量数据带入缓冲池，并驱逐等量的旧数据，即使新数据不再使用。类似地，由预读后台线程加载且只访问一次的页面被移动到新列表的头部。这些情况可以将经常使用的页面推到旧的子列表中，在那里它们将被删除。

为应对这种情况，innodb在进入new sublist增加了在old sublist的停留时间innodb_old_blocks_time（默认1000ms），也就是在这个时间间隔内，就不会从old移动到new区

预读

在上面的LRU中提到了预读，那么在innodb中预读是如何表现的呢？

  • linear: 当一个区有连续56页（56是默认值，可以通过设置innodb_read_ahead_threshold改变。范围是0-64，因为最大就是64页）都被读取，那么该区所有页将会被异步预读到buffer pool
  • random: 当一个区随机13个页（13是innodb_random_read_ahead的默认值）都在buffer pool中，那么该区所有页将会被异步预读到buffer pool

innodb LRU在原来LRU的基础上重点是尽快驱逐那些较少使用的数据，为此引入了分段式的链表以及从old到new的时间限制

其实这两个手段很大程度上都是在解决预读所引发的问题，前者是由于预读机制的存在，可能会导致大量并没有实际访问过的数据驱逐了少量实际访问的数据；后者则是因为全表扫描之类情况扫描了全表数据，又因为预读的存在，多读了一次会使得被扫描的数据直接到new sublist

这算得是是一种应对这两种情况的好手段，我在想相比于改良版的k-lru究竟孰强孰弱呢？毕竟只要k设置的合理，这两种情况其实都能避免，只是说k-lru多引入了对访问次数的维护

buffer pool内存管理

在buffer pool中内存管理主要是针对空闲页（也就是如何很快地分配空闲页）以及脏页（也就是如何很快地刷新到持久化储存）

对此，采用了free链表、flush链表分别设计用来管理空闲页和脏页，那样就能很快锁定需要的页，而不需要全部扫描

Ref

  1. https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html
  2. https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-read_ahead.html
  3. https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_old_blocks_time
  4. https://xiaolincoding.com/mysql/buffer_pool/buffer_pool.html
Innodb Buffer Pool缓存机制（二）innodb_buffer_pool_size等参数篇
moneywenxue的博客
05-22 6881
在MySQL5.5之前，广泛使用的和默认的存储引擎是MyISAM。MyISAM使用操作系统缓存来缓存数据。InnoDB需要innodb buffer pool中处理缓存。所以非常需要有足够的InnoDB buffer pool空间。
MySQL InnoDB Buffer Pool 不足 排查与优化全流程（超详细版）
weixin_43991457的博客
05-13 775
文章主要探讨了MySQL数据库响应变慢的问题，特别是InnoDB Buffer Pool配置不当导致的性能瓶颈。首先，文章描述了问题现象，包括磁盘IOPS飙升、CPU负载高、物理磁盘读取频繁等。接着，解释了InnoDB Buffer Pool的原理及其在减少磁盘IO、提升读写性能中的作用。文章进一步分析了导致Buffer Pool性能问题的核心成因，如配置过小、热点数据集过大、SQL查询不优化等，并提供了详细的排查步骤和优化解决方案，包括增大Buffer Pool大小、SQL优化、热冷数据分离、表碎片优化等
mysql之InnoDB Buffer Pool 深度解析与性能优化
qq_43460315的博客
02-22 2109
InnoDB Buffer Pool 是 MySQL InnoDB 存储引擎中至关重要的内存组件，它作为磁盘数据页和 CPU 之间的缓冲层，显著提升了数据访问速度，是 MySQL 性能优化的核心。深入理解 Buffer Pool 的工作原理和调优策略，对于构建高性能 MySQL 应用至关重要。InnoDB Buffer Pool 是 MySQL 性能优化的基石，合理配置和调优 Buffer Pool 可以显著提升数据库性能。
MySQL InnoDB Buffer Pool详解：原理、配置与性能优化
持续输出Java相关知识
08-23 923
InnoDB BufferPool 是 MySQL 的核心内存缓存机制，通过解决磁盘 I/O 瓶颈提升数据库性能。其设计基于局部性原理，将频繁访问的数据页缓存在内存中，并通过 LRU 链表、Free 链表和 Flush 链表管理缓存页。BufferPool 支持多实例配置以减少锁竞争，并通过脏页刷新机制确保数据持久性。关键参数如 innodb_buffer_pool_size、innodb_io_capacity 和 innodb_max_dirty_pages_pct 需根据硬件和工作负载调优。监控命中率
InnoDB Buffer Pool 缓冲池详解
真正的大师，永远怀着一颗学徒的❤
10-27 4501
InnoDB Buffer Pool缓冲池详解
MySQL 内存缓冲池 InnoDB Buffer Pool Sizes 深度解析
良月柒
05-27 1731
InnoDB Buffer Pool是InnoDB存储引擎用于缓存表和索引数据的主要内存结构。它的主要功能是将经常访问的数据页保存在内存中，从而减少磁盘I/O操作，提高数据库的读写性能。InnoDB Buffer Pool是MySQL中提升性能的关键组件之一。合理配置和优化Buffer Pool大小及实例数量，可以显著提高数据库的读写性能。在实际应用中，应根据系统的内存资源、数据量和并发访问情况，动态调整Buffer Pool配置，并通过监控工具持续优化数据库性能。
MYSQL innodb buffer pool 原理与监控
sql server的专栏
07-29 357
最近一段时间忙，尤其对MYSQL的原理的知识感觉到生疏了，所以还是的从新来过，让一些知识在重新印到脑子里面。今天就从 innodb buffer pool 开始。作为MYSQL 重要的组成部分innodb buffer pool 一直是一个关注到疏忽的点，大部分DB人员对其的认识1INNODBbuffer pool 为基于MYSQL的 INNODB数据库引擎的数据...
InnoDB 的 Buffer Pool 详解
csdn_tom_168的博客
07-06 1012
摘要：InnoDB的Buffer Pool是MySQL的核心内存组件，作为磁盘和内存之间的高速缓存层，主要作用是缓存数据页和索引页，减少磁盘I/O，提升数据库读写性能。其内部通过Free List、LRU List和Flush List等机制管理内存页，采用改进的LRU算法进行页面淘汰。关键特性包括预读机制、脏页刷新策略、多实例化设计等。Buffer Pool大小设置对性能至关重要，建议设为物理内存的50%-75%。MySQL 5.6+支持Buffer Pool预热功能，可通过SHOW ENGINE INN
MySQL InnoDB Buffer Pool
qq_34125999的博客
12-15 946
1 缓存的重要性 我们知道，对于使用 InnoDB 作为存储引擎的表来说，不管是用于存储用户数据的索引（包括聚簇索引和二级索引），还是各种系统数据，都是以页的形式存放在表空间中的，而所谓的表空间只不过是 InnoDB 对文件系统上一个或几个实际文件的抽象，也就是说我们的数据说到底还是存储在磁盘上的。 但是磁盘的速度慢，所以 InnoDB 存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中，也就是说即使我们只需要访问一个页的一条记录，那也需要先把整个页的数据加载到内存
MySql innodb buffer pool
QuillChen的博客
12-10 826
show variables where variable_name in ('innodb_buffer_pool_size','innodb_file_per_table','innodb_log_buffer_size','innodb_page_size','key_buffer_size','query_cache_size'); 测试数据库： innodb_buffer_pool_size：buffer pool大小 ， 4294967296byte =4GB innodb_page_size
MySQL性能优化InnoDB buffer pool flush策略
09-16
MySQL 性能优化 InnoDB buffer pool flush 策略 MySQL 中 InnoDB 存储引擎使用 buffer pool 来缓存从磁盘读取到内存的数据页。Buffer pool 通常由数个内存块加上一组控制结构体对象组成。内存块的个数取决于 buffer...
InnoDB 的 Buffer Pool
Casual_Lei的博客
07-16 960
InnoDB 的 Buffer Pool 是提高数据库性能的关键组件，通过将频繁访问的数据缓存到内存中，减少磁盘 I/O 操作。配置和优化 Buffer Pool 大小、管理 LRU 链表、合理配置多个实例以及监控 Buffer Pool 使用情况，都是提升数据库性能的重要措施。理解和掌握 Buffer Pool 的工作原理和管理方法，可以帮助数据库管理员更有效地优化 MySQL 数据库的性能。
MySQL 无缝迁移到达梦：前置方法与全面评估分析指南
最新发布
数记
12-20 986
MySQL迁移至达梦数据库（DM）的兼容性评估与迁移策略摘要 本文系统分析了从MySQL迁移到达梦数据库的关键步骤： 兼容性评估：检查表结构、SQL语法、存储过程等对象的兼容性，对比事务隔离、字符集等特性差异，使用达梦工具（如DTS、SQL Checker）辅助分析。 工作量分级：根据适配难度分为低（直接兼容）、中（语法调整）、高（代码重写）和阻断项（需业务改造），示例评估显示存储过程改造占比最高（40%）。 迁移实施：分阶段进行试点验证、灰度同步（dmdrs工具）和全量切换，结合达梦DTS工具自动转换，配
基于 MySQL Monitoring and Management 的性能保障实践
星哥玩云
12-17 966
摘要：本文探讨MySQL Monitoring and Management（MMM）工具在数据库性能保障中的实践应用。MMM作为官方推荐的轻量化监控方案，具有全栈指标覆盖、易部署和可视化告警等优势。重点分析了查询执行时间、连接数和缓存命中三大核心指标的监控逻辑与优化策略，并提供了从部署到日常监控的完整操作流程。通过电商平台案例展示了MMM在实际场景中的故障定位与性能优化价值，最后提出指标联动、动态阈值调整等优化建议，为构建高效的MySQL监控体系提供实用指南。
Canal深度解析：MySQL增量数据订阅与消费实战
qq_41262225的博客
12-18 823
Canal实战指南：MySQL增量数据同步利器 Canal是阿里巴巴开源的MySQL增量数据订阅组件，基于MySQL主从复制协议实现毫秒级数据同步。核心原理是伪装成MySQL从库，通过解析binlog获取数据变更，支持Row格式的binlog解析。典型应用场景包括缓存同步、实时数据分析、数据异构迁移等。 Canal架构包含三个核心组件：EventParser负责连接MySQL并解析binlog；EventSink进行数据过滤和路由；EventStore存储事件数据。部署时需配置MySQL开启binlog并设
MySQL 入门实验：环境搭建与基础操作全攻略
m0_71868960的博客
12-18 947
服务管理是基础：操作 MySQL 前务必确认服务已启动，否则会导致登录失败工具选择看场景：命令行适合快速执行简单命令，MySQL Workbench 可视化界面更适合复杂操作和结果查看SQL 语句规范：关键字建议大写（如 CREATE、SELECT），字段名和表名尽量见名知义，语句结尾可加英文分号主键约束很重要：创建表时设置主键（如学号）可保证数据唯一性，避免重复记录通过本次实验，不仅熟悉了 MySQL 的基本运行环境，更掌握了数据库操作的核心流程。
【一次线上 MySQL 死锁问题的完整复盘与解析】
gjc592的博客
12-19 1459
MySQL死锁问题分析及解决方案 本文详细分析了电商订单系统中出现的INSERT死锁问题。通过排查死锁日志发现，两个并发事务在向order_items表插入数据时，因同时等待对方释放idx_order_id索引上的间隙锁而导致死锁。深入分析表明，在RR隔离级别下，INSERT操作会触发间隙锁和插入意向锁的组合，当多个事务交叉请求这些锁时可能形成环形等待。文章提出了四种解决方案：1)实现事务自动重试机制；2)谨慎降低隔离级别；3)优化索引设计；4)采用批量插入和顺序提交策略。最后强调理解InnoDB锁机制和学
OpenEuler 系统中安装 MySQL
张晨光老师的播客
12-19 994
本教程适用于 OpenEuler 20.03 LTS、22.03 LTS 等主流版本，全程使用 root 权限操作（也可通过sudo提升权限）。一、环境准备1.1 检查系统版本与权限首先登录 OpenEuler 系统，执行以下命令确认系统版本，确保符合安装要求：bash运行。
MySQL：内置函数
Visual_progress的博客
12-20 842
MySQL内置函数是数据库提供的实用工具，主要包括三类：日期函数（如CURRENT_DATE()获取当前日期、DATEDIFF计算日期差）、字符串函数（如CONCAT拼接字符串、SUBSTRING截取子串）和数学函数（如ROUND四舍五入、RAND生成随机数）。这些函数无需了解实现细节，只需调用即可完成日期处理、字符串操作和数学计算等常见任务，能有效简化SQL语句编写。此外还包括USER()查询当前用户、MD5()加密等实用功能，为数据处理提供了便利。
mysql innodb buffer pool 的淘汰机制是什么？
08-08
<think>我们正在讨论MySQL InnoDB Buffer Pool的淘汰机制。根据引用[2]和引用[3]，我们知道Buffer Pool使用了一种基于LRU（最近最少使用）算法的淘汰机制，但进行了优化，以避免全表扫描等操作导致的热数据被淘汰的问题。具体来说，InnoDB将LRU链表分为两个部分：新生代（new sublist）和老生代（old sublist）。默认情况下，新生代占5/8，老生代占3/8。 当新页面读入Buffer Pool时，它首先被插入到老生代的头部（即整个LRU链表的5/8位置，也就是老生代的头部）。这样，全表扫描等操作一次性加载的大量数据会首先进入老生代，而不会直接进入新生代，从而避免它们立即淘汰新生代中的热点数据。 当页面被访问时，如果该页面已经在老生代中，并且在其被加载后存活了一段时间（通过参数`innodb_old_blocks_time`设置，默认1000毫秒），那么再次访问该页面时，它会被移动到新生代的头部。如果在设定的时间内被再次访问，则不会移动，因为可能只是临时访问（如全表扫描）。 淘汰过程发生在当Buffer Pool需要空间来加载新页面时。InnoDB会从LRU链表的尾部（即老生代的尾部）开始淘汰页面。如果老生代的页面被修改过（成为脏页），则需要先将其刷新到磁盘（由后台线程完成）才能被淘汰。 此外，Buffer Pool还通过其他链表管理，如free链表（记录空闲缓存页）、flush链表（记录脏页）等，但淘汰机制主要基于改进的LRU链表。 现在，我们根据这些信息来回答用户的问题。</think>### MySQL InnoDB Buffer Pool 淘汰机制工作原理 MySQL InnoDB Buffer Pool 的淘汰机制采用**改进型LRU算法**（Least Recently Used，最近最少使用），通过多层链表结构和冷热数据分离策略优化传统LRU算法，避免全表扫描等操作污染热数据。具体工作原理如下： #### 一、核心数据结构 1. **LRU链表**（核心淘汰控制） - 分为两个子链表： - **新生代（New Sublist）**：存放热点数据，占5/8空间 - **老生代（Old Sublist）**：存放新加载或低频数据，占3/8空间 - 链表头部为最近访问数据，尾部为待淘汰数据 2. **Free链表** - 管理空闲缓存页，当需要加载新页时从此链表获取空间 3. **Flush链表** - 记录被修改过的脏页（需刷盘） #### 二、淘汰流程 1. **新数据插入** - 新页首次加载时插入老生代头部（非LRU头部） ```mermaid graph LR A[磁盘数据页] --> B{Buffer Pool空间} B -->|有空闲页| C[从Free链表取页] B -->|无空闲页| D[触发淘汰] D --> E[淘汰老生代尾部页] E --> F[新页插入老生代头部] ``` 2. **数据访问规则** - 访问老生代数据时： - 若数据在内存中停留时间 < `innodb_old_blocks_time`（默认1000ms），保持原位 - 若停留时间 ≥ 该阈值，则移至新生代头部 - 访问新生代数据时直接移至新生代头部 3. **淘汰触发条件** - 当Free链表无空闲页时 - 淘汰顺序： 1. 从老生代尾部选取未修改的干净页直接淘汰 2. 若老生代无干净页，则淘汰新生代尾部页 3. 若需淘汰脏页，需先加入Flush链表由后台线程刷盘 #### 三、关键优化设计 1. **冷热隔离** - 全表扫描加载的数据仅存在老生代，避免冲击热数据 - 通过`innodb_old_blocks_pct`调整老生代比例（默认37%） 2. **时间窗口保护** - `innodb_old_blocks_time`参数建立时间屏障，防止短期访问污染新生代 3. **批量淘汰** - 每次淘汰触发时清理多个页面（避免频繁淘汰影响性能） #### 四、参数配置示例 ```sql -- 查看关键参数 SHOW VARIABLES LIKE 'innodb_old_blocks_pct'; -- 老生代占比 SHOW VARIABLES LIKE 'innodb_old_blocks_time'; -- 冷数据保护时间(ms) ``` > **设计意义**：此机制有效平衡了高频访问数据的留存与突发数据加载的影响，在TPCC测试中可使查询性能提升10倍以上[^2][^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值