3 亿行大表批量 DELETE 归档：chunk 大小与批次间隔怎么定才能让 undo history list 不失控？有没有「purge 追得上」的量化判据和监控方案？

背景

MySQL 8.0.32 / InnoDB，单主 32C128G（NVMe），innodb_buffer_pool_size=48G，innodb_purge_threads=4，innodb_log_file_size=4G。核心表 t_payment_flow（支付流水）约 3.2 亿行、.ibd 约 480GB，6 个二级索引（含 2 个按 created_at 的范围索引），白天 OLTP 写入 QPS 约 1200（INSERT 为主 + 少量状态 UPDATE），innodb_stats_auto_recalc 已关、ANALYZE 定时在 05:00 跑（我之前在统计信息漂移上踩过坑）。

每天凌晨 02:00–05:00 有一个归档任务：把 90 天前的流水从主表 DELETE 到冷存（Parquet），单批约 1200–1500 万行，持续 2.5 小时。

现象

1. 批删窗口内，业务方报点查 P99 从 3ms 涨到 28ms，持续约 40 分钟——performance_schema 抓下来不是锁、不是 IO wait，是 MVCC 版本链遍历变长（Innodb_rows_read 跳了 3 倍，buffer pool 命中率仍 99.6%）；
2. SHOW ENGINE INNODB STATUS 里 History list length 峰值 280 万，DELETE 结束后 12 分钟才回落到 5 万以下；
3. 6 个二级索引的 Data_free 在批删后累计涨了 38GB（碎片化），但 .ibd 文件没缩；
4. 批删本身单批 50k 行 LIMIT、批次间 sleep 200ms 的节奏跑了 3 小时 40 分，比预期慢 50%。

已尝试的排查与结果

• 调大 purge 线程：innodb_purge_threads 4→8，History list 峰值降到 190 万，但点查 P99 只降了 3ms——说明瓶颈不是 purge 消费速率，是 DELETE 产生 undo 的速率超过了 purge 的稳态处理能力；
• 缩小 chunk 到 10k + sleep 500ms：批删总时长拉到 6 小时+，History list 峰值降到 40 万，但归档窗口不够用；
• 按 created_at 范围切片 + 单事务 DELETE 100 万行：单事务 undo 膨胀到 1.2GB，批删结束后 25 分钟 History list 才清零，长事务卡 purge 的代价比预期高得多；
• 关掉 innodb_change_buffering：对点查 P99 影响不明显（±2ms），排除了 change buffer 合并干扰；
• 看了站内两篇高赞文章（见引用），确认了 History list > 100 万时点查退化的机制，但没有找到「批删期间 purge 追不追上」的量化判据。

期望得到的答案形态

1. chunk 大小与批次间隔的定量关系：在 3 亿行 + 6 二级索引的表上，「单批 N 行 × 间隔 T ms」的组合怎么推？有没有比「拍脑袋试」更系统的推导路径（比如基于 purge 线程的稳态消费速率反推）？
2. 「purge 追得上」的监控判据：批删进行中，该盯哪几个指标（History list length 增速 vs 下降速率？Innodb_purge_rows_removed 的 delta？undo log 文件大小？）？阈值怎么定？有没有一个「安全区间」可以让批删跑在 purge 稳态能力之内？
3. 6 个二级索引的碎片化治理：批删期间二级索引的页删除密度怎么实时观测？是批删后统一 OPTIMIZE 还是分批重建？对白天 1200 QPS 写入的影响怎么量化评估？
4. 有没有更轻量的归档路径：比如用 DELETE ... WHERE id BETWEEN ? AND ? 按主键范围切片（避免二级索引扫描开销），或者先 ALTER TABLE ... PARTITION BY RANGE 然后 DROP PARTITION（但 3.2 亿行加分区的 DDL 代价怎么评估）？

我想要的不是「建议调大 purge 线程」这种通用建议——上面已经试过了，效果有限。我关心的是在 DELETE 产生 undo 的速率和 purge 消费 undo 的速率之间找到稳态平衡点，以及批删窗口内如何实时观测这个平衡是否被打破。