先给出结论：Undo Log页被锁定本身并不直接造成CheckPoint延迟，真正阻塞进程的元凶，是长事务导致purge线程无法正常运行，使得Undo记录无法被及时清理，进而拖慢CheckPoint的推进速度。如何判断？观察以下三个指标的联动关系：History list length超过10000且持续上升、PURGE PROCESSED数值长时间静止不动、Trx id counter与Purged up to之间的差距不断拉大——这正是purge卡死的典型特征。

Undo Log页被锁定时为什么会导致CheckPoint延迟？

CheckPoint延迟的根本原因，并非“Undo页被锁”这个动作本身，而是InnoDB在推进CheckPoint时需要刷脏页并回收undo log空间。若undo页被一个仍在执行的长事务牢牢持有，purge线程就无法清理过期的undo记录，CheckPoint自然陷入停滞——说白了，这是undo log purge发生交通堵塞，而非锁本身的问题。

如何确认purge阻塞造成了CheckPoint滞后？

密切关注SHOW ENGINE INNODB STATUS中PURGE部分的几个关键指标：

• History list length如果超过10000，并且仍在增长——说明undo log已堆积如山，purge线程完全跟不上清理速度。
• PURGE PROCESSED长时间不更新，或者更新速度极慢——意味着purge线程几乎处于“罢工”状态。
• Trx id counter与Purged up to之间的差值不断扩大——事务ID快速递增，但purge始终追赶不上，导致undo空间无法被复用。

此时即使将innodb_max_purge_lag设置为0也无济于事，因为buffer pool中存在大量“逻辑上可刷、物理上不能丢弃”的undo相关脏页，CheckPoint只能原地等待。

哪些操作会实际锁定undo页并拖慢purge？

并非所有事务都会造成影响——真正让purge动弹不得的，是那些使undo record无法安全回收的场景：

• 未提交的长事务（TRX_STATE = RUNNING，且TRX_STARTED时间远早于当前时间）
• 将innodb_lock_wait_timeout设置得极低，但应用层既不回滚也不提交，导致事务长期悬空
• 执行SELECT ... FOR UPDATE或UPDATE后，忘记执行COMMIT或ROLLBACK，始终占用空间
• 在READ COMMITTED隔离级别下未关闭autocommit，执行完DML后立即断开连接——事务未提交，purge也无法操作

值得提醒的是：MySQL 8.0+默认启用innodb_undo_log_truncate = ON，但truncate触发的前提是history list length足够小。如果purge已经卡死，truncate将永远等不到满足条件的那一刻。

定位具体阻塞源的实用操作步骤

不要只盯着INNODB_TRX，而应联合查询三张系统表：

• 找出最老的活跃事务：SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED ASC LIMIT 1;
• 查看该事务持有哪些undo段：SELECT * FROM information_schema.INNODB_UNDO_LOGS WHERE TRX_ID = ?;（需要根据TRX_ID反查）
• 检查purge线程状态：SELECT * FROM performance_schema.threads WHERE NAME LIKE '%purge%';，观察PROCESSLIST_STATE是sleeping还是waiting for undo log

如果发现某个事务的TRX_MYSQL_THREAD_ID对应的应用连接已经断开，但事务状态仍为RUNNING——恭喜，你遇到了线上最常见的purge阻塞根源：客户端异常退出，事务未被清理。

不过，定位问题只是第一步，真正的难点在于“查到后不敢直接KILL”。强行KILL一个正在写入大量undo的事务，会触发同步回滚，处理时间可能比让它自然完成还要长。最稳妥的做法是先联系业务方确认该事务是否可以中断，再决定是执行KILL还是等待其自行结束。