Functionality Added or Changed
The mysqladmin and
mysqldump clients now have
--plugin-dir options for specifying which
authentication plugin and plugin directory to use.
(Bug #58139, Bug #11765201)
sql_priv.h now includes an
OPTION_ALLOW_BATCH flag for the
feature of MySQL Cluster.
Boolean system variables can be enabled at run time by setting
them to the value
OFF, but previously this did not work at
server startup. Now at startup such variables can be enabled by
setting them to
TRUE. Any other nonnumeric value is
OFF. (Bug #46393 improves on
this such that
recognized, and other values are invalid.)
(Bug #51631, Bug #11759326)
References: See also Bug #11754743.
In the audit plugin interface, the
MYSQL_AUDIT_CONNECTION_CLASS event class was
added, and the
subclass was added to the
MYSQL_AUDIT_GENERAL_CLASS event class. The
new symbol definitions can be found in the
plugin_audit.h header file.
Security Fix: A security bug was fixed. (Bug #57952)
UPDATE statement for an
InnoDB table could be slower than
necessary if it changed a column covered by a prefix index, but
did not change the prefix portion of the value. The fix improves
performance for InnoDB 1.1 in MySQL 5.5 and higher, and the
InnoDB Plugin for MySQL 5.1.
(Bug #58912, Bug #11765900)
Synchronization inside InnoDB frequently involves the use of
spin loops: while
waiting, InnoDB executes a tight loop of instructions repeatedly
to avoid having the InnoDB
threads be rescheduled by the
operating system. If the spin loops are executed too quickly,
system resources are wasted, imposing a performance penalty on
transaction throughput. Most modern processors implement the
PAUSE instruction for use in spin loops, so
the processor can be more efficient.
InnoDB now uses the
PAUSE instruction in its
spin loops on all platforms where such an instruction is
PAUSE instruction only on Windows
systems. Use of the
increases overall performance with CPU-bound workloads, and
provides the added benefit of minimizing power consumption
during the execution of the spin loops.
InnoDB tables in
REFERENTIAL_CONSTRAINTS were slower
than necessary because statistics were rechecked more often than
required, even more so when many foreign keys were present. The
improvement to this may be of particular benefit to users of
MySQL Enterprise Monitor with many monitored servers or tens of
thousands of tables.
(Bug #43818, Bug #11752585)
auto_increment_increment is greater than
one, values generated by a bulk insert that reaches the maximum
column value could wrap around rather producing an overflow
As a consequence of the fix, it is no longer possible for an
auto-generated value to be equal to the maximum
UNSIGNED value. It is still possible to store that
value manually, if the column can accept it.
(Bug #39828, Bug #11749800)
Important Change; Partitioning:
Date and time functions used as partitioning functions now have
the types of their operands checked; use of a value of the wrong
type is now disallowed in such cases. In addition,
col_name is a
DATETIME column, is now
disallowed altogether because its return value depends on the
value of the
(Bug #54483, Bug #11761948)
References: See also Bug #57071, Bug #11764255.
The partitioning handler did not pass locking information to a
table's storage engine handler. This caused high contention
and thus slower performance when working with partitioned
The presence of a double quotation mark inside the
COMMENT field for a column could prevent a
foreign key constraint from being created properly.
(Bug #59197, Bug #11766154)
InnoDB buffer pools
ENGINE INNODB statements displayed information about
each one, but not summary information combining statistics for
the entire buffer pool subsystem. Now, the aggregated
information is displayed in the
BUFFER POOL AND
MEMORY section, and information about individual
buffer pool instances is displayed in a new
BUFFER POOL INFO section.
The command to create a debug build (
...) now automatically sets the
InnoDB debugging flag
UNIV_DEBUG on all platforms. Formerly, the
UNIV_DEBUG flag might not be set for Windows
platforms with Visual Studio and not on OS X with Xcode.
InnoDB status output, the value
I/O sum could be incorrect, displayed
as a very large number.
The server could crash with an assertion error, if a stored
procedure, stored function, or trigger modified one
InnoDB table containing an
column, and dropped another
table containing an auto-increment column.
... TRUNCATE PARTITION statements were written to the
... PARTITION statements could cause memory leaks.
(Bug #56380, Bug #11763641)
References: See also Bug #46949, Bug #11755209, Bug #56996, Bug #11764187.
INSERT DELAYED statement
with a single inserted value does not return any visible
warnings, such a warning could be still written into the error
(Bug #57666, Bug #11764793)
References: See also Bug #49567.
Replication: When closing a session that used temporary tables, binary logging could sometimes fail with a spurious Failed to write the DROP statement for temporary tables to binary log. (Bug #57288)
Due to changes made in MySQL 5.5.3, settings made in the
system variables affected both the binary log statement cache
(also introduced in that version) and the binary log
transactional cache (formerly known simply as the binary log
cache). This meant that the resources used as a result of
setting either or both of these variables were double the amount
expected. To rectify this problem, these variables now affect
only the transactional cache. The fix for this issue also
introduces two new system variables
which affect only the binary log statement cache.
In addition, the
variable was incremented whenever either cache was used, and
incremented whenever the disk space from either cache was used,
which caused problems with performance tuning of the statement
and transactional caches, because it was not possible to
determine which of these was being exceeded when attempting to
troubleshoot excessive disk seeks and related problems. This
issue is solved by changing the behavior of these two status
variables such that they are incremented only in response to
usage of the binary log transactional cache, as well as by
introducing two new status variables
which are incremented only by usage of the binary log statement
The behavior of the
variable with regard to active sessions has also been changed to
match that of the
variable: Previously, a change in
effect in existing sessions; now, as with a change in
binlog_cache_size, a change in
effect only in sessions begun after the value was changed.
By default, a value is generated for an
AUTO_INCREMENT column by inserting either
NULL or 0 into the column. Setting the
SQL mode suppresses this behavior for 0, so that it occurs only
NULL is inserted into the column.
This behavior is also followed on a replication slave (by the
slave SQL thread) when applying events that have been logged on
the master using the statement-based format. However, when
applying events that had been logged using the row-based format,
ignored, which could lead to an assertion.
To fix this issue, the value of an
AUTO_INCREMENT column is no longer generated
when applying an event that was logged using the row-based row
format, as this value is already contained in the changes
applied on the slave.
References: This bug is a regression of Bug #50038.
BINLOG statement modified the
values of session variables, which could lead to problems with
operations such as point-in-time recovery. One such case
occurred when replaying a row-based binary log which relied on
OFF at the session level to create and populate a set
InnoDB tables having foreign key
USE statements to its output only
when the default database changed between events. To illustrate
how this could cause problems, suppose that a user issued the
following sequence of statements:
CREATE DATABASE mydb; USE mydb; CREATE TABLE mytable (
column_definitions); DROP DATABASE mydb; CREATE DATABASE mydb; USE mydb; CREATE TABLE mytable (
When played back using mysqlbinlog, the
CREATE TABLE statement
failed with Error: No Database Selected
because the second
was not played back, due to the fact that a database other than
mydb was never selected.
This fix ensures that mysqlbinlog outputs a
USE statement whenever it reads
one from the binary log.
(Bug #50914, Bug #11758677)
Replication: Previously, when a statement failed with a different error on the slave than on the master, the slave SQL thread displayed a message containing:
The error message for the master error code
The master error code
The error message for the slaves error code
The slave error code
However, the slave has no information with which to fill in any print format specifiers for the master message, so it actually displayed the message format string. To make it clearer that the slave is not displaying the actual message as it appears on the master, the slave now indicates that the master part of the output is the message format, not the actual message. For example, previously the slave displayed information like this:
Error: "Query caused different errors on master and slave. Error on master: 'Duplicate entry '%-.192s' for key %d' (1062), Error on slave: 'no error' (0). Default database: 'test'. Query: 'insert into t1 values(1),(2)'" (expected different error codes on master and slave)
Now the slave displays this:
Error: "Query caused different errors on master and slave. Error on master: message format='Duplicate entry '%-.192s' for key %d' error code=1062 ; Error on slave: actual message='no error', error code=0. Default database: 'test'. Query: 'insert into t1 values(1),(2)'" (expected different error codes on master and slave)
Replication: When an error occurred in the generation of the name for a new binary log file, the error was logged but not shown to the user. (Bug #46166)
References: See also Bug #37148, Bug #11748696, Bug #40611, Bug #11750196, Bug #43929, Bug #51019.
Comparisons of aggregate values with
TIMESTAMP values were incorrect.
(Bug #59330, Bug #11766259)
DIV expressions, assignment of
the result to multiple variables could cause a server crash.
(Bug #59241, Bug #11766191)
References: See also Bug #8457.
could return an incorrect result in some cases.
(Bug #59211, Bug #11766165)
mysqlslap failed to check for a
NULL return from
mysql_store_result() and crashed
trying to process the result set.
(Bug #59109, Bug #11766074)
In a subquery, a
UNION with no
referenced tables (or only a reference to the
DUAL virtual table) did not permit an
ORDER BY clause.
(Bug #58970, Bug #11765950)
Configuring MySQL with
Several Valgrind warnings were fixed. (Bug #58948, Bug #59021)
max_allowed_packet was set larger than
16MB, the server failed to reject too-large packets with
“Packet too large” errors.
(Bug #58887, Bug #11765878)
NOT IN predicate with a subquery containing
HAVING clause could retrieve too many rows,
when the subquery itself returned
(Bug #58818, Bug #11765815)
Release builds on Linux now are compiled with
(Bug #58766, Bug #11765769)
EXPLAIN could crash for queries
that accessed two derived tables.
On Solaris, the MySQL build failed if it was configured with debugging enabled. (Bug #58699)
EXPLAIN EXTENDED for a
query that would use condition pushdown could cause
mysqld to crash.
(Bug #58553, Bug #11765570)
An assertion could be raised for queries for which the optimizer could choose between Index Merge range access or const ref access methods. (Bug #58456)
If MySQL was built with Visual Studio Express, the project wixca was not built. (Bug #58411)
CMake polluted the source tree by writing installation-related temporary files there. (Bug #58372)
Security context references in
were rewritten for improved DTrace compatibility.
ucs2 character set does not support
characters outside the Basic Multilingual Plane (BMP), but
ucs2 a string containing such
characters did not produce a conversion-failure warning.
A Valgrind failure occurred in
(Bug #58205, Bug #11765259)
CMake did not add
An assertion could be raised if the server was closing a session at the same time the session was being killed by another thread. (Bug #58136)
Condition pushdown optimization could push down conditions with incorrect column references. (Bug #58134, Bug #11765196)
Configuration with maintainer mode enabled resulted in errors when compiling with icc. (Bug #57991, Bug #58871)
ORDER BY clause was bound to the incorrect
substatement when used in
BIT_AND() function could
return incorrect results when a join returned no matching rows.
If the set of values aggregated with
AVG(DISTINCT) contained a
NULL value, the function result could be
In rare cases,
failed for an indexed column that used a collation containing
Unnecessary subquery evaluation in contexts such as statement preparation or view creation could cause a server crash. (Bug #57703)
View creation could produce Valgrind warnings. (Bug #57352)
NULL geometry values could cause a crash in
It was possible to compile mysqld with Performance Schema support but with a dummy atomic-operations implementation, which caused a server crash. This problem does not affect binary distributions. It is helpful as a safety measure for users who build MySQL from source. (Bug #56769)
cp1251 character set did not properly
support the Euro sign (
0x88). For example,
converting a string containing this character to
utf8 resulted in
rather than the
utf8 Euro sign.
Some unsigned system variables could be displayed with negative values. (Bug #55794)
An assertion could be raised during concurrent execution of
DROP DATABASE and
REPAIR TABLE if the drop deleted
.TMD file at the same time the
repair tried to read details from the old file that was just
After compilation from source, all header files were installed in the same directory, even those that should be installed into subdirectories of the installation include directory. (Bug #51925)
When mysqld printed crash dump information, it incorrectly indicated that some valid pointers were invalid. (Bug #51817)
On Mac OS X, a configuration error caused the preference pane to fail. (Bug #51264)
On FreeBSD, if mysqld was killed with a
SIGHUP signal, it could corrupt
(Bug #51023, Bug #11758773)
An assertion could be raised if –1 was inserted into an
AUTO_INCREMENT column by a statement writing
more than one row.
(Bug #50619, Bug #11758417)
If a client supplied a user name longer than the maximum 16 characters permitted for names stored in the MySQL grant tables, all characters were being considered significant when checking for a match. Historically, only the first 16 characters were used for matching; this behavior was restored. (Bug #49752)
my_tell() functions ignored the
MY_WME flag when they returned an error,
which could cause client programs to hang.
During assignment of values to system variables, legality checks on the value range occurred too late, preventing proper error checking. (Bug #43233)