High InnoDB History List Length (HLL)<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } What is History List Length? History List Length counts how many undo records InnoDB still needs to purge. The History list is a change history that is kept in the redo log for rollback purposes. InnoDB keeps multiple versions of rows to support transactions (MVCC). After transactions commit, old versions are removed by the background purge threads. If purge falls behind, HLL grows. Metric name: "History list length"Where it lives: In InnoDB's undo/rollback segmentsWhy it matters: Big backlogs → more I/O and memory overhead, slower consistent reads, bigger undo tablespaces, and sometimes replication delays How customers notice the problem (Symptoms) : General slowness—especially reads that need consistent snapshots (e.g., long SELECTs)Growing undo tablespace size (e.g., undo_001, undo_002, or shared system tablespace growth in older versions)Replication falling behind (longer Seconds_Behind_Master/Replica_IO/SQL lag)Long metadata locks or DDLs taking longer than expectedMonitoring alerts on "History list length" or "Purge lag"Usually queries run on sys_trigger all the time and you could see sys_trigger table and queries on sys_trigger get impacted as soon as we see very high HLL. Jobs could get impacted as sys_trigger will be bloated with fragmentation. Why HLL becomes high (Common causes) Long-running database transactions (open read-only SELECTs, idle transactions in autocommit=0 sessions, uncommitted writes, DDLs, Alter with nocopy ).Heavy write bursts outpacing purge capacity.Problematic DDLs that rebuild/copy tables, generating a lot of undo and long metadata locks.Too few purge threads or slow storage throttling purge progress. What to do when there is high HLL Support kills the long running queries on the database they are still running.Support to Rebuild sys_trigger if sys_trigger is bloated (fragmented) due to high HLL.Confirm that the history list length is low or coming down.Continue to monitor the HLL and frequently check for fragmentation on sys_trigger. Once the HLL comes down, please check for any fragmentation on sys_trigger table again. If it is fragmented, it probably needs to be rebuild again.