innodb_purge_threads默认值为1（5.6+），单线程易导致undo积压、history list length飙升、ibdata1不收缩；需据cpu核数（≤8核设2–4，≥12核可设4–8）、io能力及undo表空间配置综合调优，并同步调整innodb_max_dirty_pages_pct、innodb_purge_batch_size等参数。
innodb_purge_threads 控制独立执行 Undo 日志清理（purge）的后台线程数量，直接影响历史版本快照（MVCC 中的旧数据页）的回收速度和表空间释放效率。配置不当会导致 undo 表空间持续膨胀、ibdata1 文件不断增长，甚至引发磁盘满或 purge 延迟堆积。
为什么需要调高 innodb_purge_threads
默认值为 1（MySQL 5.6+），所有 purge 工作由单个线程串行处理。当写入压力大（如高频 UPDATE/DELETE）、事务生命周期长、或 undo 表空间较大时，单线程 purge 跟不上生成速度，造成：
- undo 日志积压，
INFORMATION_SCHEMA.INNODB_METRICS中purge_trx和purge_undo指标持续升高 - 历史版本数据无法及时清理，
SHOW ENGINE INNODB STATUS的 PURGE 部分显示 “history list length” 居高不下（例如 > 10000） - 即使执行了
OPTIMIZE TABLE或TRUNCATE，ibdata1 文件也不收缩（因为 purge 未完成，undo 页仍被引用）
合理设置线程数的依据
不是越多越好，需结合 CPU 核心数、IO 能力与 purge 压力综合判断：
- 物理 CPU 核心总数 ≤ 8：设为 2～4
- 12 核及以上（如你提到的 2×12 核）：推荐设为 4，高并发写入场景可尝试 6～8
- SSD/NVMe 环境 + 较大 buffer pool：可适当提高，但一般不超过 8，避免线程争抢 IO 资源
- 若使用独立 undo 表空间（
innodb_undo_tablespaces > 1），多线程 purge 效果更明显
配套必须调整的关键参数
单独调高 innodb_purge_threads 效果有限，需同步优化以下几项：
- innodb_max_dirty_pages_pct：建议设为 30～50（默认 75）。降低脏页上限，让刷盘更积极，间接减轻 purge 压力
- innodb_purge_batch_size：默认 300，可适度增大到 500～1000（每轮 purge 处理更多 undo 记录）
-
innodb_undo_log_truncate：MySQL 5.7+ 必须开启（
= ON），配合innodb_undo_tablespaces ≥ 2才能真正截断并释放 undo 空间 - innodb_undo_retention：根据业务最长一致性读需求设定（如 3600 秒），过大会阻碍 purge；不需强一致性读的系统可设低些（如 600）
验证 purge 是否生效
修改后重启 MySQL，通过以下方式确认效果：
- 运行
SHOW ENGINE INNODB STATUS\G，关注 “PURGE PROCESSED” 和 “HISTORY LIST LENGTH” 是否稳定下降 - 查性能视图：
SELECT * FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'purge%'; - 监控
INFORMATION_SCHEMA.INNODB_TRX中长时间未提交事务，避免它们拖慢全局 purge 进度
