控制InnoDB LRU链表的两个参数------innodb_old_blocks_time和innodb_old_blocks_pct

本文深入探讨了InnoDB缓存池中LRU(最近最少使用)机制的两个关键参数:innodb_old_blocks_pct和innodb_old_blocks_time。详细解释了它们如何影响页面在缓存池中的分布和移动策略,以及如何通过调整这些参数来优化数据库性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

innodb_old_blocks_time和innodb_old_blocks_pct

innodb_old_blocks_pct:
    1)全局、动态变量,默认值 37,取值范围为5~95。
    2)Specifies the approximate percentage of the InnoDB buffer pool used for the old block sublist

innodb_old_blocks_time
    1)全局、动态变量,默认值 1000,取值范围为0~2**32-1,单位ms。
    2)Specifies how long in milliseconds a block inserted into the old sublist must stay there after its first access before it can be moved to the new sublist.
         If the value is 0, a block inserted into the old sublist moves immediately to the new sublist the first time it is accessed, no matter how soon after insertion the access occurs.
         If the value is greater than 0, blocks remain in the old sublist until an access occurs at least that many milliseconds after the first access. 
         For example, a value of 1000 causes blocks to stay in the old sublist for 1 second after the first access before they become eligible to move to the new sublist.

innodb_old_blocks_pct用来确定LRU链表中old sublist所占比例
innodb_old_blocks_time用来控制old sublist中page的转移策略,新的page页在进入LRU链表中时,会先插入到old sublist的头部,然后page需要在old sublist中停留innodb_old_blocks_time这么久后,下一次对该page的访问才会使其移动到new sublist的头部,
该参数的设置可以保护new sublist,尽可能的防止其being filled by page that is referenced only for a brief period。

 

<think>嗯,用户想要一个关于改进的LRU缓存机制的结构图,特别是InnoDB缓冲池中的新旧分区页面管理流程。首先,我需要回忆一下InnoDBLRU机制。传统的LRU是最近最少使用,但InnoDB做了改进,分成newold两个链表,这样可以避免全表扫描时的缓冲池污染问题。 接下来,结构图需要展示这两部分,可能包括链表的划分、页面插入的位置、访问后的移动逻辑以及淘汰机制。用户可能希望看到各个步骤的流程,比如页面首次进入old区,再次被访问时如何提升到new区,以及淘汰时是从old区的尾部开始。 然后,用户提到的页面管理流程可能需要更详细的步骤,比如缓冲池初始化时如何划分区域,页面的加载过程,访问后的处理,以及当缓冲池满时的淘汰策略。需要确保这些步骤在图中能够清晰呈现,可能需要用箭头表示流程方向,用方框表示不同的区域操作。 还要注意引用部分,用户提供的参考资料中提到InnoDB缓冲池的重要性以及它与操作系统缓存的区别。结构图应该反映出数据库特有的管理逻辑,比如写入顺序特殊用途的优化,这可能需要在注释或图例中说明。 另外,用户可能需要这个结构图来帮助理解缓冲池的工作原理,或者进行性能调优。因此,图应该尽可能简洁,同时涵盖关键点,比如新旧分区的比例(如3/85/8),页面移动的条件(如innodb_old_blocks_time参数的作用),以及淘汰策略的具体步骤。 最后,需要确认结构图的格式。用户可能希望有文本描述的结构图,或者用某种图示工具绘制。但根据问题描述,可能更倾向于文本形式的描述,辅以说明,或者指导如何用工具绘制。可能需要建议使用流程图工具,并用文字详细解释每个部分,确保用户能够根据描述自行绘制出正确的结构图。</think>### 改进的LRU缓存机制与InnoDB缓冲池页面管理流程 #### 结构图核心要素(文字描述) 1. **LRU链表分区** - `New Sublist`(热数据区):存储频繁访问的页面,占比约5/8 - `Old Sublist`(冷数据区):存储新加载或低频访问的页面,占比约3/8 $$ \text{LRU链表} = [\text{New区头部}] \leftrightarrow \cdots \leftrightarrow [\text{New区尾部}] \leftrightarrow [\text{Old区头部}] \leftrightarrow \cdots \leftrightarrow [\text{Old区尾部}] $$ 2. **页面插入流程** - 新页面首次加载时插入Old区头部 - 通过参数`innodb_old_blocks_time`控制:页面在Old区驻留时间超过设定阈值后,再次访问才会晋升到New区[^2] 3. **页面移动逻辑** ```plaintext ┌─────────────┐ ┌─────────────┐ │ 页面被访问 │───是──>│ 是否在Old区 │───是──>移动到New区头部 └─────────────┘ └─────────────┘ │ │否 │ ↓ │ 保持在当前位置附近(New区内移动) │ └───否───> 位置不变(可能逐渐向尾部滑动) ``` 4. **页面淘汰机制** - 优先淘汰Old区尾部的页面 - 当缓冲池空间不足时,从LRU链表尾部(Old区尾部)开始淘汰 - 通过后台线程`Page Cleaner`定期刷新脏页[^1] #### InnoDB缓冲池管理流程 ```mermaid graph TD A[缓冲池初始化] --> B[划分New/Old区域] B --> C[新页面加载到Old区头部] C --> D{页面是否被再次访问?} D -- 是且超过阈值 --> E[晋升到New区头部] D ----> F[逐渐向Old区尾部移动] E --> G{New区是否已满?} G ----> H[淘汰New区尾部页面到Old区头部] F --> I{缓冲池空间不足?} I ----> J[淘汰Old区尾部页面] ``` #### 关键设计特性 1. **冷热隔离**:通过分区防止全表扫描等批量操作污染热数据区 2. **晋升延迟**:`innodb_old_blocks_time`参数避免短期高频访问误判为热数据 3. **异步刷新**:后台线程定期将脏页刷回磁盘,减少事务提交延迟 4. **动态调整**:New/Old区比例可通过参数`innodb_old_blocks_pct`配置(默认37%) 建议使用流程图工具(如Draw.io/Mermaid)绘制动态交互过程,需特别注意标注: - 页面状态转换条件 - 各区域的比例参数 - 淘汰操作的触发阈值 - 与磁盘IO的交互节点 : 数据库缓存包含特殊用途的逻辑(例如写入顺序)以帮助满足这些需求 : InnoDB缓冲池需要为缓存分配更多的内存,使用缓存来避免磁盘访问
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值