MySQL 5.5.25 is superseded by MySQL 5.5.25a due to a regression bug that can cause excessive disk usage (for details, see Bug #65745). Current users of 5.5.25: Upgrade to 5.5.25a. Users contemplating an upgrade to 5.5.25: Upgrade to 5.5.25a instead.
Functionality Added or Changed
Important Change; Replication:
SHOW BINARY LOGS statement
(and its equivalent
LOGS) may now be executed by a user with the
REPLICATION CLIENT privilege.
was necessary to use either form of this statement.)
--safe-mode server option now
is deprecated and will be removed in MySQL 5.6.
Performance; InnoDB: Improved the algorithm related to adaptive flushing. This fix increases the rate of flushing in cases where compression is used and the data set is larger than the buffer pool, leading to eviction. (Bug #13990648, Bug #65061)
status variable was incorrectly set to twice the value it should
be. Its value should never exceed the value of
(Bug #14000361, Bug #65030)
In a transaction using the
READ isolation level, an
DELETE statement for an
InnoDB table could sometimes overlook rows
recently committed by other transactions. As explained in
Consistent Nonlocking Reads, DML statements within
REPEATABLE READ transaction apply to rows
committed by other transactions, even if a query could not see
(Bug #14007649, Bug #65111)
InnoDB: The error handling and message was improved for attempting to create a foreign key with a column referencing itself. The message suggested a potential problem with the data dictionary, when no such problem existed. (Bug #12902967)
CHECK TABLE statement could
fail for a large
InnoDB table due to a
timeout value of 2 hours. For typical storage devices, the issue
could occur for tables that exceeded approximately 200 or 350
GB, depending on I/O speed. The fix relaxes the locking
performed on the table being checked, which makes the timeout
less likely. It also makes
CHECK TABLE QUICK, which avoids
the possibility of the timeout entirely.
(Bug #11758510, Bug #50723)
It was theoretically possible for concurrent execution of more
than one instance of
EVENTS to crash the MySQL Server.
RAND(), or user variables could
be applied in the wrong context on the slave when using
statement-based replication and replication filtering server
options (see How Servers Evaluate Replication Filtering Rules).
(Bug #11761686, Bug #54201)
References: See also Bug #11754117, Bug #45670, Bug #11746146, Bug #23894.
INSERT into a table that has a
composite primary key that includes an
AUTO_INCREMENT column that is not the first
column of this composite key is not safe for statement-based
binary logging or replication. Such statements are now marked as
unsafe and fail with an error when using the
STATEMENT binary logging format. For more
information, see Determination of Safe and Unsafe Statements in Binary Logging,
as well as
This issue does not affect tables using the
InnoDB storage engine, since an
InnoDB table with an
column requires at least one key where the auto-increment
column is the only or leftmost column.
(Bug #11754117, Bug #45670)
References: See also Bug #11761686, Bug #54201, Bug #11746146, Bug #23894.
For queries with
ORDER BY COUNT(*) and
LIMIT, the optimizer could choose an
execution plan that produced incorrect results.
SHOW TABLES was very slow unless
the required information was already in the disk cache.
(Bug #60961, Bug #12427262)
When dumping the
mysqldump did not include the
slow_query_log tables because they cannot be
locked. This caused a problem after reloading the dump file if
that file contained a
DATABASE statement for the
database: The database no longer contained the log tables and
attempts to log to them failed. Now mysqldump
includes statements to re-create the
slow_query_log tables so that they exist
after loading the dump file. Log table contents still are not
(Bug #45740, Bug #11754178)