The default transaction level for InnoDB is REPEATABLE READ. A more permissive level is READCOMMITTED, which is known to work well. While the REPEATABLE READ level maintains the transaction history up to the start of the transaction, READCOMMITTED maintains the transaction history up to the start of the current statement. Peter Zaitsev described the differences between how these modes are handled in this blog post. Both can theoretically cause performance slowdowns, but READCOMMITTED is usually seen as fast-working – at least on a typical MySQL machine (owned by Percona):

The default transaction isolation mode for PostgreSQL is also READCOMMITTED. Originally, I wanted to use this mode for MySQL tests as well. But when I tested on a machine with 144 cores, I found that after 36 threads, REPEATABLE READ continued to scale while READCOMMITTED slowed down. It then got stuck at about 3x slower results for standard OLTP RW tests.

Dimitri Kravtchuk wrote about performance issues with READ COMMITTED in 2015, but he tested with 40 cores that time. My tests show that there is a huge difference after 40 cores.

I tested this originally with Percona Server 5.7.15 and recently re-tested with Oracle’s MySQL versions 5.6.35 and 5.7.17. I confirmed that the bug exists in these versions as well, and reported it. The good news is that while 5.6 stopped scaling after 16 threads, 5.7 improves this to 36 threads.