InnoDB has been upgraded to version 1.1. This
version is considered of Beta quality.
debuginfo RPM packages are no longer being
built or published.
Functionality Added or Changed
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
committed. Starting in InnoDB 1.1 with MySQL 5.5, these two
kinds of operations are protected by separate mutexes, with a
log_buf mutex controlling writes to
buffer pool pages due to mini-transactions.
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 1.1 with MySQL 5.5, the
InnoDB has 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
InnoDB from starting, the
system 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
The redo scan during
InnoDB recovery used
excessive CPU. The efficiency of this scan was improved,
significantly speeding up crash recovery. For additional
Optimizing InnoDB Configuration Variables.
(Bug #49535, Bug #29847)
InnoDB page-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
The AIX implementation of
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)
InnoDB did not reset table
AUTO_INCREMENT values to the last used values
after a server restart.
When using the
EXAMPLE storage 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