Important Change; Replication: The SHOW BINARY LOGS statement (and its equivalent SHOW MASTER LOGS) may now be executed by a user with the REPLICATION CLIENT privilege. (Formerly, the SUPER privilege was necessary to use either form of this statement.)

The --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)

InnoDB: The Innodb_buffer_pool_pages_flushed status variable was incorrectly set to twice the value it should be. Its value should never exceed the value of Innodb_pages_written. (Bug #14000361, Bug #65030)

InnoDB: In a transaction using the REPEATABLE READ isolation level, an UPDATE or DELETE statement for an InnoDB table could sometimes overlook rows recently committed by other transactions. As explained in Consistent Nonlocking Reads, DML statements within a REPEATABLE READ transaction apply to rows committed by other transactions, even if a query could not see those rows. (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)

InnoDB: The 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 InnoDB recognize the syntax CHECK TABLE QUICK, which avoids the possibility of the timeout entirely. (Bug #11758510, Bug #50723)

Replication: It was theoretically possible for concurrent execution of more than one instance of SHOW BINLOG EVENTS to crash the MySQL Server. (Bug #13979418)

Replication: Statements using AUTO_INCREMENT, LAST_INSERT_ID(), 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.

Replication: An 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 Replication and AUTO_INCREMENT.

(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. (Bug #12713907)

SHOW TABLES was very slow unless the required information was already in the disk cache. (Bug #60961, Bug #12427262)

When dumping the mysql database, mysqldump did not include the general_log and slow_query_log tables because they cannot be locked. This caused a problem after reloading the dump file if that file contained a DROP DATABASE statement for the mysql database: The database no longer contained the log tables and attempts to log to them failed. Now mysqldump includes statements to re-create the general_log and slow_query_log tables so that they exist after loading the dump file. Log table contents still are not dumped. (Bug #45740, Bug #11754178)