AWS Aurora 5.6 MySQL RDS历史列表长度持续过高问题咨询

针对Aurora MySQL 5.6版本，没有统一的绝对阈值，业内通用的健康判断标准如下：

• 常规业务场景下，HLL稳定在1万以内属于正常状态
• 峰值超过10万且10分钟内没有回落趋势，就需要排查长事务风险，你当前13万的数值已经属于需要介入排查的区间
• 当HLL超过百万级时，会明显拖慢查询性能：一致性读请求需要遍历更多undo日志版本才能获取对应的数据快照，你之前遇到的4000多万的极端值就是性能恶化的直接诱因

你的推测基本正确。你看到的Trx read view will not see trx with id >= 43269350781, sees < 43268006946中的43268006946是当前读视图的低水位线，代表InnoDB purge线程默认可以清理所有事务ID小于该值的undo日志。如果这个低水位线长期不推进，说明存在持有旧读视图的长事务没有释放，哪怕这个事务本身已经没有执行SQL（比如应用端开启事务后未提交/回滚就把连接放回了连接池），哪怕对应事务ID不在活跃事务列表中，只要读视图还被持有，purge线程就无法清理之前的undo版本，直接导致HLL持续上涨。

• 执行SHOW PROCESSLIST;筛选Command列为Sleep、且Time列超过业务最大合理事务执行时长（通常建议设为300秒）的线程，这类线程就是可能持有未释放事务和读视图的闲置长连接
• 调整数据库参数wait_timeout和interactive_timeout为合理值（比如300秒），MySQL会自动断开超过阈值的闲置连接，释放持有的事务资源
• 执行SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;可以直接查询所有活跃的InnoDB事务，包含事务启动时间、持有的锁、关联的线程ID，确认长事务后可以用KILL [线程ID]命令手动清理
• 可基于information_schema.processlist和INNODB_TRX表编写定期巡检脚本，自动清理超时长的闲置事务，避免资源长期占用

死锁确实是推高HLL的诱因之一：死锁发生时被回滚的事务对应的undo日志需要等待purge线程清理，如果同时存在大量死锁，叠加读视图不释放的问题，会大幅加剧undo日志堆积。优化方案如下：

• 开启innodb_print_all_deadlocks = 1参数，所有死锁信息会打印到错误日志中，定期分析死锁日志，调整业务SQL的执行顺序、缩小加锁粒度
• 避免大事务，将大事务拆分为多个小事务执行，减少锁持有时间，降低死锁概率
• 确保事务涉及的所有查询都使用合适的索引，索引缺失会导致InnoDB扫描全表加行锁，大幅提升死锁发生的概率
• 业务层面增加死锁重试机制，出现死锁后自动重试事务，避免事务挂起占用资源

内容的提问来源于stack exchange，提问作者Evelyn Dibben