InnoDB: Starting with InnoDB 1.1 with MySQL 5.5, concurrent access to the buffer pool is faster. Operations involving the flush list, a data structure related to the buffer pool, are now controlled by a separate mutex and do not block access to the buffer pool.
InnoDB: The mutex known as the log sys mutex has historically done double duty, controlling access to internal data structures related to log records and the LSN, as well as pages in the buffer pool that are changed when a mini-transaction is committed. Starting in InnoDB 1.1 with MySQL 5.5, these two kinds of operations are protected by separate mutexes, with a new
log_bufmutex controlling writes to buffer pool pages due to mini-transactions.
InnoDB: Starting in
InnoDB1.1 with MySQL 5.5, the asynchronous I/O capability that
InnoDBhas had on Windows systems is available on Linux systems. (Other Unix-like systems continue to use synchronous I/O calls.) This feature improves the scalability of heavily I/O-bound systems, which typically show many pending reads/writes in the output of the command
SHOW ENGINE INNODB STATUS\G.
If there is a problem with the asynchronous I/O subsystem in the OS that prevents
InnoDBfrom starting, the new
innodb_use_native_aiosystem variable, which is enabled by default, can be disabled at startup. This variable applies to Linux systems only, where the MySQL server now has a dependency on the
Performance; InnoDB: The redo scan during
InnoDBrecovery used excessive CPU. The efficiency of this scan was improved, significantly speeding up crash recovery. For additional details, see Optimizing InnoDB Configuration Variables. (Bug #49535, Bug #29847)
InnoDBpage-freeing operations were made faster for compressed blocks, speeding up
DROP TABLE, and other operations on compressed tables that free compressed blocks. One symptom of the older behavior could be 100% CPU use during these operations. (Bug #35077)
InnoDB: The AIX implementation of
InnoDBerrors. (Bug #50691)
InnoDB: The limit of 1023 concurrent data-modifying transactions has been raised. The limit is now 128 × 1023 concurrent transactions that generate undo records. You can remove any workarounds that require changing the proper structure of your transactions, such as committing more frequently or delaying DML operations to the end of a transaction.
The limit of 1023 concurrent data-modifying transactions was due to a bottleneck with the InnoDB rollback segment. Previously, a single rollback segment supported 1023 transactions that perform writes. The single rollback segment is now divided into 128 segments, each of which can support up to 1023 transactions that perform writes, for a total of approximately 128K concurrent transactions. Read-only transactions do not count against that maximum.
Each transaction is assigned to one of the rollback segments, and remains tied to that rollback segment for the duration. This enhancement improves both scalability (higher number of concurrent transactions) and performance (less contention when different transactions access the rollback segments).
If upgrading to from MySQL 5.1 or earlier, do a slow shutdown before upgrading or some time afterward to take advantage of this feature. InnoDB makes the required changes inside the system tablespace automatically, the first time you restart after performing a slow shutdown. (Bug #26590)
A unique index on a column prefix could not be upgraded to a primary index even if there was no primary index already defined. (Bug #51378)
InnoDBdid not reset table
AUTO_INCREMENTvalues to the last used values after a server restart. (Bug #49032)
When using the
EXAMPLEstorage engine, when the engine had been built as a plugin (instead of built in), and DTrace probes had been enabled during the build, loading the storage engine library failed due to a missing object table entry.