压测造数后的清理：怎么判断"清干净了"才敢开下一轮？purge/undo 残留怎么观测，别让上一轮脏数据污染下一轮 p99 基线

背景 15 年测开，现在负责一条订单+库存链路的性能压测（JDK17 + Spring Boot 3.1，MySQL 8.0 InnoDB 单主，k6 压测）。每个接口压测前会造一批"前置依赖数据"（用户/商品/库存，量级 20 万～500 万行），压测后由 teardown 阶段调删除接口 + 定时批量清理兜底。近期出现"同一套脚本，今天 p99 干净、明天 p99 尾巴变长"，怀疑和造数/清理没闭环有关。

现象

• 连跑两轮，第二轮的 p99 尾部比第一轮系统性偏高 8%～15%，但平均延迟几乎一样——典型的"尾部被上一轮残留拖长"的味道；
• 清理用的是 pt-archiver 按 PK 切批删除（每批 5000 行，批间 sleep 20ms），跑完一轮约 1h50m；
• 清理结束后立刻开下一轮压测，有时正常、有时慢，复现不了，只能靠"多等等再压"碰运气；
• 我怀疑和 InnoDB 的 undo/redo 未 purge、二级索引残留、或造数批次里混进了非压测数据有关，但没有观测手段确认。

已尝试的排查与结果

1. 清理后查 SELECT COUNT(*) 确认目标表行数归零——能归零，但 p99 仍偶发偏长，说明"行数清干净"≠"引擎状态清干净"；
2. 看了 SHOW ENGINE INNODB STATUS 的 History list length，清理刚跑完时几千～几万，压测前又涨回去——但我没建立"多少算安全"的判断基线；
3. 试过一次 OPTIMIZE TABLE 强制回收，单表 400 万行要跑 20+ 分钟且锁表现差，不敢放进自动化流程；
4. 造数脚本目前每次全量重建（20 万行约 40 分钟），没做"一次构建、多轮复用"，造数本身也占压测窗口预算。

期望得到的答案形态

• 一套可落地的"清理完成度观测清单"：除了 COUNT(*)，还应看哪些指标（History list length、innodb_history_list_length 阈值、SHOW BINARY LOGS 的 undo 空间、磁盘水位、SHOW TABLE STATUS 的 Data_free 等），以及各自的"安全基线"怎么定；
• 怎么判断"上一轮残留不会污染下一轮 p99"：给一个可自动化的判据（比如 purge 落后量 < N、Data_free 回收完成才允许开下一轮），而不是"多等等再压"；
• 造数侧：批量造数如何从"每次全量重建"改成"一次构建 + 轮间只清理被改动行"，以及怎么保证复用的数据状态是"未污染"的（结合 MVCC/快照读，避免用例互相"看不见"或"看见脏行"）。

引用依据

• 批量删除批大小与 purge 取舍的讨论，可参考陈知远-212 的提问（id=638）；
• 造数吞吐侧可参考林墨白的批量插入量化复盘（id=520）。