Performance: InnoDB uses random numbers to generate dives into indexes for calculating index cardinality. However, under certain conditions, the algorithm did not generate random numbers, so ANALYZE TABLE did not update cardinality estimates properly. A new algorithm has been introduced with better randomization properties, together with a system variable, innodb_use_legacy_cardinality_algorithm, that controls which algorithm to use. The default value of the variable is 1 (ON), to use the original algorithm for compatibility with existing applications. The variable can be set to 0 (OFF) to use the new algorithm with improved randomness. (Bug#43660)

Replication: Restarting the replication slave — either by using STOP SLAVE plus START SLAVE, or by restarting the slave mysqld process — could sometimes cause the slave to crash when using a debug version of the server. (Bug#38694)

Replication: Killing the thread executing a DDL statement, after it had finished its execution but before it had written the binlog event, caused the error code in the binlog event to be set (incorrectly) to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED, which caused replication to fail. (Bug#37145)

See also Bug#27571, Bug#22725.

Replication: Column aliases used inside subqueries were ignored in the binary log. (Bug#35515)

Replication: The statements DROP PROCEDURE IF EXISTS and DROP FUNCTION IF EXISTS were not written to the binary log if the procedure or function to be dropped did not exist. (Bug#13684)

See also Bug#25705.

Use of HANDLER statements with INFORMATION_SCHEMA tables caused a server crash. Now HANDLER is prohibited with such tables. (Bug#44151)

myisamchk could display a negative Max keyfile length value. (Bug#43950)

mysqld_multi incorrectly passed --no-defaults to mysqld_safe. (Bug#43876)

On Windows, a server crash occurred for attempts to insert a floating-point value into a CHAR column with a maximum length less than the converted floating-point value length. (Bug#43833)

UNION of floating-point numbers did unnecessary rounding. (Bug#43432)

Certain statements might open a table and then wait for an impending global read lock without noticing whether they hold a table being waiting for by the global read lock, causing a hang. Affected statements are SELECT ... FOR UPDATE, LOCK TABLES ... WRITE, TRUNCATE TABLE, and LOAD DATA INFILE. (Bug#43230)

The InnoDB btr_search_drop_page_hash_when_freed() function had a race condition. (Bug#42279)

Compressing a table with the myisampack utility caused the server to produce Valgrind warnings when it opened the table. (Bug#41541)

For a MyISAM table with DELAY_KEY_WRITE enabled, the index file could be corrupted without the table being marked as crashed if the server was killed. (Bug#41330)

Multiple-table UPDATE statements did not properly activate triggers. (Bug#39953)

The functions listed in Section 11.12.4.2.3, “Creating Geometry Values Using MySQL-Specific Functions”, previously accepted WKB arguments and returned WKB values. They now accept WKB or geometry arguments and return geometry values.

The functions listed in Section 11.12.4.2.2, “Creating Geometry Values Using WKB Functions”, previously accepted WKB arguments and returned geometry values. They now accept WKB or geometry arguments and return geometry values. (Bug#38990)

An UPDATE statement that updated a column using the same DES_ENCRYPT() value for each row actually updated different rows with different values. (Bug#35087)

For shared-memory connections, the read and write methods did not properly handle asynchronous close events, which could lead to the client locking up waiting for a server response. For example, a call to mysql_real_query() would block forever on the client side if the executed statement was aborted on the server side. Thanks to Armin Schöffmann for the bug report and patch. (Bug#33899)

CHECKSUM TABLE was not killable with KILL QUERY. (Bug#33146)

myisamchk and myisampack were not being linked with the library that enabled support for * filename pattern expansion. (Bug#29248)

COMMIT did not delete savepoints if there were no changes in the transaction. (Bug#26288)

Several memory allocation functions were not being checked for out-of-memory return values. (Bug#25058)