8000 万行大表批量 UPDATE 后 30 分钟读 P99 飙 5 倍：如何量化 buffer pool LRU 逐出影响

【背景】 MySQL 8.0.32 / InnoDB，单库承载订单查询与归档。核心表 t_order 约 8000 万行、数据文件 15.2GB（含二级索引约 22GB），innodb_buffer_pool_size=16GB（机器 64GB，其余留给 OS cache 与其他库）。日常在线查询（按 merchant_id + create_time 取最近 100 条）P99 稳定在 8~12ms，buffer pool hit ratio 99.7%+。

每天 03:00 有一个归档批处理： UPDATE t_order SET archive_flag=1, gmt_modified=NOW() WHERE create_time < DATE_SUB(NOW(), INTERVAL 180 DAY) AND archive_flag=0 LIMIT 500000 循环执行直到影响行数为 0，单次事务约 50 万行，整个批处理持续约 40 分钟。

【现象】 批处理完成并提交后，在线查询的 P99 从 10ms 飙到 200~500ms，持续约 25~35 分钟后自然恢复。关键监控数据：

1. 批处理结束后 history list length 在 2 分钟内从 18 万降到 <2000（purge 很快）；
2. SHOW ENGINE INNODB STATUS 无活跃事务、无锁等待；
3. iostat：批处理结束后 30 分钟内，磁盘 await 从 0.2ms 涨到 4~6ms，util 从 3% 涨到 28%（ESSD PL2，远未打满）；
4. Innodb_buffer_pool_reads（物理读）从平时 200/min 涨到 12000/min，持续 30 分钟后回落；
5. 慢日志（long_query_time=0.05）抓到的慢查询全是同一类在线 SELECT，耗时集中在 150~450ms；
6. 把 buffer pool 临时调到 32GB 后重跑，恢复时间从 30 分钟缩短到 12 分钟，但 P99 峰值仍到 180ms。

【已尝试的排查与排除】

• 排除锁：批处理提交后无活跃事务，Innodb_row_lock_waits 增量为 0；
• 排除 undo / purge：history list length 在批处理结束后 2 分钟内已清零，purge 不是瓶颈；
• 排除 redo / checkpoint：innodb_log_file_size=4GB，checkpoint age 始终 <20%；
• 排除 OS 层：vmstat 无 swap，/proc/vmstat 的 pgscan_direct 为 0，不是 OOM 或 direct IO 压力；
• 排除连接池：HikariCP pending 始终为 0，无排队；
• 怀疑是 LRU 逐出：8000 万行的 UPDATE 触碰大量 buffer pool 页，把热读页（约占 15GB 中的 8~10GB）挤出了 young 区，后续在线查询被迫做随机磁盘读。但拿不出一个量化证据链来证明"被逐出的具体是哪些页、逐出量是多少、为什么 30 分钟后才恢复"。

【期望得到的答案形态】

1. 有没有一套从 buffer pool 内部状态 → 量化 LRU 逐出量 → 预测恢复时间的方法？比如：
   • 怎么读 information_schema.INNODB_BUFFER_POOL_STATS 或 INNODB_BUFFER_PAGE 来统计"批处理前后 hot page 的命中率变化"？
   • Innodb_buffer_pool_reads 与 Innodb_buffer_pool_read_requests 的比值怎么用来判断"是逐出还是 IO 带宽瓶颈"？
   • 有没有办法在批处理执行期间采样 buffer pool 的 LRU 链表状态，看到 hot page 被逐出的速率？
2. 如果确认是 LRU 逐出，结构化解法有哪些？各自的代价和适用边界：
   • 把 t_order 按 create_time RANGE 分区，批处理只触碰旧分区（物理上不影响新分区的 buffer pool 页）？
   • 把归档逻辑改成"先 SELECT 出 id 列表 → 再分批 DELETE + INSERT 到归档表"，避免 UPDATE 触碰主表所有列的 buffer pool 页？
   • 用独立从库做批量操作，主库只承担在线读？（代价：主从延迟 + 数据一致性窗口）
   • 调 innodb_old_blocks_time / innodb_old_blocks_pct 来保护 hot page？这个参数在 8.0 里还有效吗？
3. 压测 / 灰度时，怎么稳定复现"批处理 → 30 分钟 P99 飙升"这个现象，并拿到一个可量化的归因报告（逐出页数、恢复曲线、IO 带宽利用率）？

希望有实战经验的朋友给一个可落地的排查 checklist，最好带具体的 SQL 查询语句和阈值判断。