InnoDB History List Length 长期 10w+ 但 processlist 无长事务，如何定位阻塞 purge 的只读会话

背景：MySQL 8.0.32 / InnoDB，单主单从，主库承载支付清结算，核心表 t_settle_record 约 2.8 亿行，innodb_purge_threads=4，隔离级别 REPEATABLE READ。业务方有一个凌晨 2 点起的报表 SELECT（全表聚合，单次跑 4 小时）。

现象：

1. SHOW ENGINE INNODB STATUS 里 History list length 从日常 2k~5k 涨到 12w+，持续 3~6 小时不降；
2. 同一时间 information_schema.processlist 里看不到明显长事务（max TIME < 30s）；
3. 表文件 t_settle_record.ibd 从 42GB 涨到 78GB，空间未回收；
4. 期间 UPDATE 的 P99 从 8ms 涨到 45ms，怀疑 undo 链变长拖慢了回滚段扫描。

已尝试的排查：

1. SELECT trx_id, trx_started, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx ORDER BY trx_started——只看到 2~3 个 <10s 的写事务，没有能解释 History list length 的会话；
2. 翻 performance_schema.events_statements_history_long，找到一条凌晨 2:14 启动、跑了 4 小时的 SELECT（全表扫），它的 trx_started 显示 2:14:01；但 processlist 里看不到它——后来才意识到是只读事务，SELECT 结束后会话没有显式 COMMIT/ROLLBACK，read view 一直挂着；
3. 重启实例后 History list length 立刻归零，说明确实是长事务（只读）挡住了 purge；
4. 把 innodb_purge_threads 从 4 调到 8，30 分钟后 History list length 纹丝不动——我怀疑 purge 线程模型不是「越多越快」，而是被 read view 卡住时线程再多也推不动。

困惑点：

• 在 RR 隔离级别下，一个只读长事务（只 SELECT、不 UPDATE）是否等价于「持有 read view」从而阻止 purge？MySQL 的 read view 释放时机到底是「事务结束」还是「SELECT 语句结束」？
• 如果 purge 被 read view 阻塞，innodb_purge_threads 调大到底有没有意义？purge 线程的工作模型是什么（每个线程处理不同 tablespace？还是同一批 undo page 分段处理？）？
• production 上有没有「不重启实例」就能让 purge 追上的手段？KILL 掉那个只读会话是否安全（会不会影响其它会话的 MVCC 视图）？

期望得到的回答形态：

1. 一段可复现的最小 SQL（建 2 张表 + 开一个长只读事务 + 跑 UPDATE）来验证「只读事务阻止 purge」，并给出 History list length 的观测命令；
2. History list length、information_schema.innodb_metrics 里的 trx_rseg_history_len、innodb_trx 三者数值在阻塞时的关系，以及各自的告警阈值建议；
3. 生产环境「长事务治理」的完整 checklist：KILL 策略（KILL 只读会话 vs KILL 写会话的差别）、监控 SQL、以及如何在应用层规范「只读事务必须短」。

希望回答者给的是可复现的最小案例 + 指标关系 + 落地 checklist，而不是「建议你优化 SQL」。