If the --with-ndbcluster option is given to the configure script, it now produces a warning that the version of MySQL Cluster included in 5.1 is no longer maintained. (The separate MySQL Cluster distribution should be used instead.) (Bug #49093, Bug #11757091)

Performance: InnoDB: This fix improves the performance of operations on VARCHAR(N) columns in InnoDB tables, where N is declared as a large value but the actual string values in the table are short. (Bug #12835650)

Performance: InnoDB: The DROP TABLE command for an InnoDB table could be very slow, in a configuration with a combination of table compression, partitioning, and a large buffer pool. (Bug #12635227, Bug #61188)

Performance: InnoDB: The “random read-ahead” feature that was removed from the InnoDB Plugin is now available again. Because it is only helpful for certain workloads, it is turned off by default. To turn it on, enable the innodb_random_read_ahead configuration option. Because this feature can improve performance in some cases and reduce performance in others, before relying on this setting, benchmark both with and without the setting enabled. (Bug #12356373)

Incompatible Change: Handling of a date-related assertion was modified.

However, a consequence of this change is that several functions become more strict when passed a DATE() function value as their argument and reject incomplete dates with a day part of zero. These functions are affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(), DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(), WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). Because this changes date-handling behavior in General Availability-status series (MySQL 5.1 and 5.5), it was reverted in 5.1.62 and 5.5.21. The change is retained in MySQL 5.6.

References: See also Bug #13458237.

InnoDB: The DATA_LENGTH column in the INFORMATION_SCHEMA.TABLES table now correctly reports the on-disk sizes of tablespaces for InnoDB compressed tables. (Bug #12770537)

InnoDB: With the configuration settings innodb_file_per_table=1 and innodb_file_format=Barracuda, inserting a column value greater than half the page size, and including that column in a secondary index, could cause a crash when that column value was updated. (Bug #12637786)

InnoDB: Unused functions were removed from the internal InnoDB code related to mini-transactions, to clarify the logic. (Bug #12626794, Bug #61240)

InnoDB: A DROP TABLE or DROP INDEX statement for an InnoDB table on a busy server could cause a crash or corrupt data in the buffer pool, if the buffer pool contained data from an InnoDB compressed table that was being accessed at the same time. (The crash could occur whether or not the table being dropped used compression.) (Bug #11765566, Bug #58549)

Partitioning: Auto-increment columns of partitioned tables were checked even when they were not being written to. In debug builds, this could lead to a server crash. (Bug #11765667, Bug #58655)

Replication: Processing of corrupted table map events could cause the server to crash. This was especially likely if the events mapped different tables to the same identifier, such as could happen due to Bug #56226.

Now, before applying a table map event, the server checks whether the table has already been mapped with different settings, and if so, an error is raised and the slave SQL thread stops. If it has been mapped with the same settings, or if the table is set to be ignored by filtering rules, there is no change in behavior: the event is skipped and IDs are not checked. (Bug #44360, Bug #11753004)

References: See also Bug #11763509.

The option-parsing code for empty strings leaked memory. (Bug #12589928)

ALTER TABLE {MODIFY|CHANGE} ... FIRST did nothing except rename columns if the old and new versions of the table had exactly the same structure with respect to column data types. As a result, the mapping of column name to column data was incorrect. The same thing happened for ALTER TABLE DROP COLUMN ... ADD COLUMN statements intended to produce a new version of the table with exactly the same structure as the old version. (Bug #61493, Bug #12652385)

For a lower_case_table_names value of 1 or 2 and a database having a mixed-case name, calling a stored function using a fully qualified name including the database name failed. (Bug #60347, Bug #11840395)

For MyISAM tables, attempts to insert incorrect data into an indexed GEOMETRY column could result in table corruption. (Bug #57323, Bug #11764487)

SELECT DISTINCT with a deterministic stored function in the WHERE clause could produce incorrect results. (Bug #59736, Bug #11766594)

A race condition between loading a stored routine using the name qualified by the database name and dropping that database resulted in a spurious error message: The table mysql.proc is missing, corrupt, or contains bad data (Bug #47870, Bug #11756013)

Upgrades using an RPM package recreated the test database, which is undesirable when the DBA had removed it. (Bug #45415, Bug #11753896)

CREATE TABLE without an ENGINE option determined the default engine at parse rather than execution time. This led to incorrect results if the statement was executed within a stored program and the default engine had been changed in the meantime. (Bug #50614, Bug #11758414)