BI 大表扫描后在线 P99 恢复窗口：如何用 buffer pool 参数预估"污染窗口"时长，以及有哪些可观测信号判断热工作集已重建完毕

背景

我负责一套 MySQL 8.0.32 / InnoDB 的订单核心库，单主 64C256G，innodb_buffer_pool_size=64GB，innodb_lru_scan_depth=256（默认值）。核心表 t_order 约 2 亿行、数据文件约 90GB，日常在线点查（按 merchant_id + status 二级索引）QPS 约 3000，热工作集（高频访问的页）估算约 12GB，P99 基线稳定在 15ms 左右。

每天下午 14:00 有一个 BI 聚合任务（非事务、只读）直接扫 t_order 全表做 GROUP BY，扫描量约 40GB 冷数据，扫描速率实测约 1.2GB/s，耗时约 33 秒。

现象

1. BI 扫描运行期间，在线点查 P99 立刻从 15ms 飙到 200~400ms（P50 基本不变，说明不是锁竞争）；
2. BI 扫描结束后，P99 不会立刻回落，而是从 800ms 开始缓慢下降，大约持续 3~8 分钟才回到 15ms 基线（具体时长每次不同，跟当时脏页比例有关）；
3. 整个过程中 Innodb_buffer_pool_read_requests / Innodb_buffer_pool_reads 算出的命中率始终 > 98%，监控上"看起来没坏"；
4. SHOW ENGINE INNODB STATUS 的 History list length 无异常，排除了 undo 积累。

已尝试的排查

• 把 BI 任务挪到只读从库：效果立竿见影，但业务方要求主库也要能跑（容灾演练场景），所以不能只靠"挪到从库"；
• 调了 innodb_lru_scan_depth 从 256 改到 1024：P99 峰值略有下降（400ms → 350ms），但恢复窗口时长基本没变；
• 在 BI 扫描前手动执行 FLUSH TABLES + 等 5 分钟：无效，buffer pool 页不会被 flush；
• 查了社区相关文章（id=510《buffer pool 命中率 99.7% 但 P99 仍 800ms》），理解了 LRU young list 冲刷的机制，但没找到"污染窗口时长"的量化预估方法；
• 查了 id=521（8000 万行批量 UPDATE 后 P99 飙 5 倍），那是写操作触发，我的场景是纯读扫描，机制类似但参数不同。

期望得到的答案形态

1. 一个可操作的公式或估算方法：给定 buffer_pool_size、热工作集大小、扫描量、扫描速率，如何预估"污染窗口"时长（即 P99 从峰值回落到基线的时间）？参数之间是什么关系，哪个是主导因素？
2. 可观测的恢复信号：在 P99 恢复期间，哪些 performance_schema 或 information_schema 指标能用来判断"热工作集已重建完毕"？（比如 Innodb_buffer_pool_pages_data 的变化趋势、某条热查询的 rows_examined 是否恢复正常？）有没有一个"恢复完成"的可观测判据？
3. 如果要在主库上跑大扫描，有没有"主动控制污染范围"的手段？比如 MySQL 8.0 的 resource group + cgroup 能否限制 BI 扫描的 I/O 带宽，从而缩短恢复窗口？或者有没有其他方法让扫描页"不进入 LRU young list"？