预读失效不是bug而是设计必然，暴露传统LRU在批量访问下结构性缺陷；MySQL冷热分离是救命机制，通过innodb_old_blocks_pct和innodb_old_blocks_time协同实现观察期淘汰，防止预读页与全表扫描页挤占热数据空间。
Buffer Pool 预读失效不是 bug，而是设计必然——它暴露的是传统 LRU 在批量访问场景下的结构性缺陷；MySQL 的冷热数据分离不是锦上添花，而是救命机制。
预读失效到底在“失”什么
预读（Read-Ahead）本身没错：InnoDB 读一个页时，顺手把相邻页也拉进 Buffer Pool，本意是减少后续磁盘 I/O。但问题出在“顺手”之后的淘汰逻辑上。
默认 LRU 链表是单链表，新页直接插到头部。预读加载的几十个页（比如全表扫描触发线性预读，一次拉一个 extent 共 64 页），全挤在链表最前面。真正高频访问的用户信息页、订单索引页，被一路推到尾部，很快被淘汰——缓存命中率断崖下跌，QPS 上不去，监控里 innodb_buffer_pool_reads 暴涨。
这种现象叫“缓存污染”，不是数据错了，是缓存管理策略没区分访问意图：
- 预读页：大概率只访问一次，属于“冷数据”
- 索引点查页：每秒被访问数百次，属于“热数据”
- 传统 LRU 把两者当同级选手排序，结果就是热数据被冷数据顶出内存
innodb_old_blocks_pct 和 innodb_old_blocks_time 怎么协同防污染
冷热分离不是加个开关就完事，关键靠两个参数配合形成“观察期”：
innodb_old_blocks_pct 控制冷区占比，默认 37%，意味着整个 LRU 链表约 3/8 是老年代（Old Sublist），5/8 是新生代（Young Sublist）；innodb_old_blocks_time 是时间门槛，默认 1000ms，决定冷页有没有资格“转正”。
所有新加载页（含预读页）强制首先进入 Old Sublist 头部，而不是 Young Sublist。只有满足两个条件才晋升：
- 该页在 Old Sublist 中存活超过
innodb_old_blocks_time（比如 1000ms） - 在此期间被再次访问（第二次 touch）
这意味着：全表扫描中被预读又只读一次的页，永远卡在 Old Sublist 尾部，很快被淘汰；而用户登录时反复查询的 users 表主键页，只要两次访问间隔超 1 秒，就会被提拔进 Young Sublist 头部，稳住位置。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
为什么调高 innodb_read_ahead_threshold 反而可能加重污染
线性预读的触发阈值 innodb_read_ahead_threshold 默认是 56（即连续访问同一 extent 中 56 个页后触发）。有人觉得“多预读更高效”，于是调到 80 甚至 100——这是危险操作。
调高阈值 ≠ 更少预读，而是让预读更“晚但更猛”：原本在第 56 页就分批预读剩余页+下一个 extent；现在等到第 80 页才一次性预读更多页。结果是：
- 单次预读数据量更大，Old Sublist 瞬间涌入更多冷页
- 如果此时并发查询多，多个大扫描同时发生，Old Sublist 迅速填满，连带挤占 Young Sublist 空间
- 实际效果是：预读总量没减，但冲击更集中，冷热分离的缓冲作用被削弱
真正有效的做法是：对已知有规律的范围扫描（如按时间分区的报表），用 FORCE INDEX + 覆盖索引减少扫描行数，从源头压低预读触发概率，而不是在预读层“硬扛”。
SHOW ENGINE INNODB STATUS 里怎么看冷热分离是否生效
执行 SHOW ENGINE INNODB STATUS\G 后，定位到 BUFFER POOL AND MEMORY 部分，重点关注三组数字：
youngs/s：每秒有多少页从 Old Sublist 晋升到 Young Sublistnon-youngs/s：每秒有多少页在 Old Sublist 内部被访问但未晋升（说明访问太密集或间隔太短）pages read ahead：当前预读总页数
健康状态参考值：
-
youngs/s应显著高于non-youngs/s（比如 5:1），说明冷页确实在“观察期”后合理晋升 -
non-youngs/s持续接近 0，可能是innodb_old_blocks_time设得太高，或者业务确实没有二次访问冷页的需求 - 若
pages read ahead突增，但youngs/s几乎为 0，基本可断定刚发生了一次全表扫描，且冷页全卡在 Old 区没动——这正是机制在起作用，别急着调参
真正容易被忽略的点是：冷热分离效果不体现在单次查询变快，而体现在系统整体缓存稳定性。哪怕某次慢查询依然慢，只要它没把用户中心表的热页顶出去，后续大量正常请求就不会连锁雪崩。
