purge 是 InnoDB 延迟物理删除的必要环节，通过 coordinator 与 worker 线程协作，依据 history list 和最老 ReadView 判断并清理不再需要的旧版本数据。
你执行了 DELETE 或 UPDATE，数据“不见了”，但磁盘没缩、history list length 却在涨——这不是异常，而是 InnoDB 的 purge 机制正在按规则工作。它不立即删，而是在确保安全后才物理清理旧版本数据。
purge 是什么：延迟物理删除的必要环节
InnoDB 为支持 MVCC 和事务回滚，不会在事务提交时立刻擦除旧数据：
- DELETE 操作只是把记录打上
delete-marked标记，行仍留在 B+ 树页中； - UPDATE 会生成新版本，并将旧版本写入 undo log，原记录也保留（带 roll pointer）；
- 真正释放空间、删除索引项、回收 undo page，要等 purge 线程判断“该版本已无人需要”后才执行。
purge 怎么判断“可以删”：依赖 history list 和 ReadView
关键依据是事务可见性规则：
- 每个已提交事务的 undo log 被加入全局 history list（历史列表），长度可通过
SHOW ENGINE INNODB STATUS中的History list length查看； - purge coordinator 会定期捕获当前最老活跃事务的 ReadView（含
m_low_limit_no）； - 只有
trx_id < m_low_limit_no的 undo 记录，才确认不再被任何现存事务读取，可进入清理队列。
purge 怎么执行：协调线程 + 工作线程协作
MySQL 5.7.8+ 默认启用多线程 purge 架构：
- 1 个 coordinator thread（
srv_purge_coordinator_thread）：负责扫描 history list、构建 purge 队列、按表分组、分发任务； -
innodb_purge_threads - 1个 worker threads（srv_worker_thread）：实际执行索引项清理、undo page 回收、B+ 树节点合并等操作； - worker 线程默认休眠，由 coordinator 通过事件唤醒，避免空转消耗。
影响 purge 效率的关键参数与信号
以下参数直接影响清理是否及时、空间能否复用：
-
innodb_purge_threads：默认 4，适合多表并发 DML；若业务集中在少数大表，可适当调低（如设为 2），减少锁竞争； -
innodb_purge_batch_size：默认 300，控制每次清理的 undo page 数量；增大可加快空间回收，但可能加剧 IO/CPU 波动，一般无需调整； -
History list length持续 > 10000 或单日增长超 5000，通常是 purge 跟不上或存在长事务（包括只读事务），需检查information_schema.INNODB_TRX； -
innodb_max_purge_lag不建议启用（默认 0），人工限流易引发 DML 延迟雪崩，应优先优化事务生命周期。
