MySQL 5.4 modifications improve performance on SMP systems to increase scalability on multi-core systems. The changes affect InnoDB locking, memory management, and thread concurrency. Much of this work is based on a patch developed by Google, about which more information can be found here:

http://code.google.com/p/google-mysql-tools/wiki/SmpPerformance

MySQL 5.4 incorporates a Google SMP patch that improves the performance of RW-locks within InnoDB. The patch changes the implementation of the RW-locks to use atomic instructions rather than mutexes. This patch also enables InnoDB memory allocation to be disabled and replaced by the normal malloc library, or by a different library that implements malloc such as tcmalloc on Linux or mtalloc on Solaris.

MySQL 5.4 also implements a lock-free method for handling InnoDB thread concurrency. This method is timer-based; it uses yield and sleep rather than mutexes that have scalability issues. The innodb_thread_concurrency_timer_based system variable determines which concurrency method to use. By default, this variable is enabled (use the lock-free method). Disabling it causes InnoDB to use the original mutex-based method.

The number of threads in use affects whether the lock-free timer-based method will be advantageous. For 256 threads, this method increases performance about 15%. For low thread counts (up to 2 times the number of cores), performance decreases about 1%.

The reimplementation of RW-locks and the lock-free thread concurrency method require atomic instructions. A new status variable, Innodb_have_sync_atomic, shows whether the server was built with atomic instructions. If Innodb_have_sync_atomic is OFF, enabling innodb_thread_concurrency_timer_based has no effect. The lock-free concurrency method also requires that innodb_thread_concurrency be set to a value greater than 0 (the default value in 5.4).

Another new status variable, Innodb_heap_enabled, indicates whether the built-in InnoDB memory manager is used. (ON means it is used, OFF means it is not.)