History list length持续增长说明undo log积压严重，反映purge滞后；需通过SHOW ENGINE INNODB STATUS获取，并结合趋势判断；真正阻塞purge的是最老活跃读视图事务，而非运行中事务。
History list length持续增长说明什么
它不是“历史版本数量”，而是已提交但尚未被purge线程清理的undo log事务数。值越大，代表旧版本数据越积压，MVCC快照链越长，undo空间越可能膨胀。如果该值稳定在个位数或百位数内，基本正常；一旦突破1万且持续上升，基本可以判定purge滞后。
这个指标只能通过SHOW ENGINE INNODB STATUS\G获取，在输出的TRANSACTIONS段里找History list length行。注意：它每秒都在变，单次查看意义有限，必须结合趋势判断——建议用脚本每5秒采集一次，持续观察10分钟以上。
怎么快速定位阻塞purge的长事务
真正卡住purge的，不是“正在运行”的事务，而是“最老的活跃读视图”（oldest active read view）——即最早那个还没结束的事务，哪怕它只是执行了一条SELECT没提交，也会让所有早于它的undo无法清理。
- 查当前最老事务：
SELECT trx_id, trx_started, trx_state, trx_mysql_thread_id FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 1; - 重点看
trx_state是否为RUNNING且trx_started时间远早于当前时间（比如几小时甚至几天前） - 再用
SHOW PROCESSLIST匹配trx_mysql_thread_id，确认对应连接是否还在、SQL是什么、客户端IP和用户是谁 - 特别注意
Command为Sleep但Time很大的连接——这往往是应用端拿了连接没释放，或者事务开启后没commit/rollback
REPEATABLE READ隔离级别会让问题更严重
默认隔离级别下，每个事务启动时会固定一个read view，直到事务结束才释放。这意味着一个只读事务如果持续10分钟，就会让这10分钟内所有已提交事务的undo全部保留——哪怕其他事务早已结束。
如果你的应用没有强一致性要求（比如报表类、统计类查询），可考虑局部降级：
- 对特定会话设为
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; - 避免在应用层长期持有事务，尤其不要在事务里做HTTP调用、文件读写等耗时操作
- 检查ORM框架（如MyBatis、Hibernate）是否默认开启事务，以及是否有未关闭的
TransactionTemplate或@Transactional作用域过宽
注意：READ COMMITTED下每次SELECT都生成新read view，undo释放更快，但可能引发不可重复读——业务逻辑得兜住。
innodb_undo_log_truncate为什么没生效
开启innodb_undo_log_truncate=ON后，InnoDB会在满足条件时自动截断undo表空间文件，但前提是：没有长事务阻塞、undo表空间为独立模式、且innodb_max_undo_log_size达到阈值。
- 先确认是否用了独立undo表空间：
SELECT NAME, SPACE_TYPE FROM information_schema.FILES WHERE SPACE_TYPE = 'Undo';—— 如果结果为空，说明还在共享表空间ibdata1里，truncate根本不起作用 - 检查
innodb_max_undo_log_size是否设置合理（默认1073741824字节≈1GB），太小会导致频繁截断，太大则延迟清理 - 即使配置正确，只要存在一个trx_started早于
purge点的事务，truncate就会被跳过——所以必须先清掉长事务，再等一轮purge周期（默认每秒触发）
真正容易被忽略的是：truncate只对inactive的undo表空间文件生效，而活跃的undo段（比如正在被事务使用的）永远不能删。所以别指望它能立刻缩小磁盘占用，它只是防止无限增长的保险阀。
