Incompatible Change: Aliases for wildcards (as in SELECT t.* AS 'alias' FROM t) are no longer accepted and result in an error. Previously, such aliases were ignored silently. (Bug#27249)

Sinhala collations utf8_sinhala_ci and ucs2_sinhala_ci were added for the utf8 and ucs2 character sets. (Bug#26474)

If the value of the --log-warnings option is greater than 1, the server now writes access-denied errors for new connection attempts to the error log (for example, if a client username or password is incorrect). (Bug#25822)

Added the PARAMETERS table to INFORMATION_SCHEMA. The PARAMETERS table provides information about stored function and procedure parameters, and about return values for stored functions.

Incompatible Change: DROP TABLE now is allowed only if you have acquired a WRITE lock with LOCK TABLES, or if you hold no locks, or if the table is a TEMPORARY table.

Previously, if other tables were locked, you could drop a table with a read lock or no lock, which could lead to deadlocks between clients. The new stricter behavior means that some usage scenarios will fail when previously they did not. (Bug#25858)

Incompatible Change: GRANT and REVOKE statements now cause an implicit commit, and thus are prohibited within stored functions and triggers. (Bug#21975, Bug#21422, Bug#17244)

MySQL Cluster: Adding a new TINYTEXT column to an NDB table which used COLUMN_FORMAT = DYNAMIC, and when binary logging was enabled, caused all cluster mysqld processes to crash. (Bug#30213)

MySQL Cluster: After adding a new column of one of the TEXT or BLOB types to an NDB table which used COLUMN_FORMAT = DYNAMIC, it was no longer possible to access or drop the table using SQL. (Bug#30205)

The server crashed on optimization of queries that compared an indexed DECIMAL column with a string value. (Bug#32262)

The server crashed on optimizations that used the range checked for each record access method. (Bug#32229)

When comparing a BLOB value that was null, memory corruption could occur casuing the server to crash. (Bug#32191)

Deleting a large number of records could sometimes take a significant amount of time. (Bug#27946)

Several buffer-size system variables were either being handled incorrectly for large values (for settings larger than 4GB, they were truncated to values less than 4GB without a warning), or were limited unnecessarily to 4GB even on 64-bit systems. The following changes were made:

In addition, settings for read_buffer_size and read_rnd_buffer_size are limited to 2GB on all platforms. Larger values are truncated to 2GB with a warning. (Bug#5731, Bug#29419, Bug#29446)