One major problem in terms of MySQL performance that still stands in the way of InnoDB scalability is the trx_list scan on consistent read view creation. It was originally reported as a part of MySQL bug #49169 and can be described as follows. Whenever a connection wants to create a consistent read, it has to make a snapshot of the transaction states to determine which transactions are seen in the view later. To this end, InnoDB scans trx_list (i.e. the list of currently open transactions) and copies IDs of transactions that have not yet been committed at the current point in time, and thus should not be visible in the consistent read. For the REPEATABLE_READ isolation level, the snapshot is created on the first SELECT …

I know that this was talked a lot and recently Mark Callaghan also gave a session in MySQL user conference 2008 about the real bottlenecks.

Other day I was testing my thread pool stuff with MySQL 5.1.24 + InnoDB plugin 1.0.1 along with other miscellaneous benchmark tests by making them CPU bound by keep the working set completely in memory to gauge the performance of threads overhead; and on 8-core box InnoDB seems to be doing better than 4-core. And then immediately I started few tests with mysqlslap by keeping complete data set in the buffer pool to get the proper timing on locking overhead.

Here is the comparison of performance on 8-core box with innodb_thread_concurrency is set to 32 and 0 for variable threads on 64-bit Redhat Linux 4 . The same box is used as …