This is essentially what innodb does, it calls this operation "purge" as in purging dead mvcc rows, and it calls the data structure the history list (IIRC). I d

This is essentially what innodb does, it calls this operation "purge" as in purging dead mvcc rows, and it calls the data structure the history list (IIRC). I don't know what the exact data structure is though to find purgable rows and how it avoids contention. The main difference is that innodb runs purge in background thread(s) as opposed to blocking foreground operations. It has potential pitfalls too though. On a system with very high mutation rate, purging could fall behind. This mainly would happen if the history list overflows available buffer pool space and starts getting paged to disk (e.g. from one very long lived transection). I don't know if newer MySQL versions make purge running off disk more efficient, but 5.5 added a config for multiple purge threads.