增大 innodb_purge_batch_size 不一定加快 Undo Log 回收，因其受 purge 线程数、活跃事务分布及 purge lag 节流共同制约；盲目调大会导致单次扫描过长、阻塞 MVCC，真正瓶颈常是长事务而非参数。
为什么增大 innodb_purge_batch_size 不一定加快 Undo Log 回收
因为 InnoDB 的 purge 线程不是只靠这个参数单点驱动的。它实际受 innodb_purge_threads 数量、undo 表空间活跃事务分布、以及 innodb_max_purge_lag 的动态节流共同约束。单纯调大 innodb_purge_batch_size 可能导致 purge 线程卡在单次扫描上，反而降低整体吞吐。
实操建议：
- 先确认 purge 是否真成瓶颈：查
SHOW ENGINE INNODB STATUS里的PURGE PROCESSED和HISTORY LIST LENGTH，后者持续 > 10000 才值得干预 -
innodb_purge_batch_size默认 300，生产环境可试 1000～3000，但必须同步增加innodb_purge_threads（至少 2～4） - 避免设为 10000+：单次 purge 扫描太久会阻塞 MVCC 快照构建，引发
Lock wait timeout exceeded类错误
Undo Log 回收慢的真正常见原因不是参数，而是长事务
History list 长的本质，是还有活跃事务在读取老版本数据（比如一个跑了 2 小时的报表查询），purge 线程不敢清理其依赖的 undo 记录。这时调任何 purge 参数都无效。
实操建议：
- 实时定位长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60; - 检查应用层是否漏关连接、或 ORM 开了过长的 session-level transaction
- 对已知需读历史数据的场景（如 binlog 解析、闪回），改用
SET TRANSACTION AS OF TIMESTAMP（MySQL 8.0.22+）替代长事务持有
innodb_purge_batch_size 和 innodb_max_purge_lag 的联动陷阱
这两个参数会互相打架。当 innodb_max_purge_lag 被触发（history list 超阈值），InnoDB 会主动延迟 DML，而此时若 innodb_purge_batch_size 过小，purge 追不上新产生的 undo，系统就陷入“越压越慢”的负循环。
实操建议：
- 若设了
innodb_max_purge_lag（比如 1000000），innodb_purge_batch_size至少设为 5000，并确保innodb_purge_threads >= 4 - 监控
Innodb_purge_delay状态变量：非 0 值说明已在限流，这是调参失败的明确信号 - 多数 OLTP 场景其实该关掉
innodb_max_purge_lag（设为 0），靠足够快的 purge 线程兜底更稳
MySQL 5.7 和 8.0 在 Undo Log 回收上的关键差异
MySQL 8.0 把 undo log 拆成独立表空间（innodb_undo_tablespaces），并支持在线 truncate（ALTER UNDO TABLESPACE ... SET ACTIVE/INACTIVE）。5.7 只能靠重启或 dump/reload 清理膨胀的 undo。
实操建议：
- 8.0 用户优先用
ALTER UNDO TABLESPACE innodb_undo_001 SET INACTIVE;，等 purge 完自动 drop，比调innodb_purge_batch_size更治本 - 5.7 用户如果 history list 居高不下，重点检查是否用了
innodb_file_per_table = OFF导致 undo 混在 ibdata1 里无法收缩 - 8.0 的
innodb_purge_batch_size实际影响的是每个 undo tablespace 内部的清理粒度，不是全局 batch
复杂点在于 purge 效率从来不是单参数问题，它卡在事务可见性判断、磁盘随机 IO、undo 表空间碎片三者的交界处。最容易被忽略的是：你看到的 “回收慢”，90% 情况下源头根本不在 purge 线程本身。
