Beginning with MySQL 5.6.10, MySQL Enterprise Edition is available for MySQL 5.6. Specifically, MySQL Enterprise 5.6.10 includes these components previously available only in MySQL 5.5: MySQL Enterprise Security (PAM and Windows authentication plugins), MySQL Enterprise Audit, and MySQL Thread Pool. For information about these features, see MySQL Enterprise Edition. To learn more about commercial products, see http://www.mysql.com/products/.
Known limitations of this release:
On Microsoft Windows, when using the MySQL Installer to install MySQL Server 5.6.10 on a host with an existing MySQL Server of a different version (such as 5.5.30), that also has a different license (community versus commercial), you must first update the license type of the existing MySQL Server. Otherwise, MySQL Installer will remove MySQL Server(s) with different licenses from the one you chose with MySQL Server 5.6.10.
On Microsoft Windows 8, updating a community release to a commercial release requires you to manually restart the MySQL service after the update.
Functionality Added or Changed
When compressed tables were used, the calculation to compute
memory usage within the buffer
pool was complex because the compressed pages could be
smaller than 16KB or the user-specified
page size. Although this
information can be retrieved from the
table, that operation is expensive. The following new status
variables help to simplify calculations involving buffer pool
Auto_Position column has been added to the
output generated by
STATUS. The value of this column shows whether
replication autopositioning is in use. If autopositioning is
enabled—that is, if
1 was set by the last successful
CHANGE MASTER TO
statement that was executed on the slave—then the
column's value is 1; if not, then the value is 0.
In RPM packages built for Unbreakable Linux Network,
libmysqld.so now has a version number.
Error messages for
statement using a
ALGORITHM value not supported for the given
operation were very generic. The server now produces more
If a client with an expired password connected but
old_passwords was not the value
required to select the password hashing format appropriate for
the client account, there was no way for the client to determine
the proper value. Now the server automatically sets the session
appropriately for the account password.
variable was renamed to
attached_condition information for
subqueries now includes
select# to indicate
the relative order of subquery execution.
The following changes were made to the sandbox mode that the server uses to handle client connections for accounts with expired passwords:
There is a new
system variable (default: enabled). This controls how the
server treats expired-password accounts.
Two flags were added to the C API client library:
mysql_real_connect(). Each flag enables a
client program to indicate whether it can handle sandbox
mode for accounts with expired passwords.
enabled for mysqltest unconditionally,
for mysql in interactive mode, and for
mysqladmin if the first command is
Performance; InnoDB: Some data structures related to undo logging could be initialized unnecessarily during a query, although they were only needed under specific conditions. (Bug #14676084)
Performance; InnoDB: Optimized read operations for compressed tables by skipping redundant tests. The check for whether any related changes needed to be merged from the insert buffer was being called more often than necessary. (Bug #14329288, Bug #65886)
Immediately after a table was created, a query against it would
not use a loose index
scan. The same query might use a loose index scan
ALTER TABLE on the
table. The fix improves the accuracy of the cost estimate for
queries involving the grouping functions
prevents the query plan from being changed by the
ALTER TABLE statement. (The more
stable query plan might or might not use a loose index scan.)
Important Change; Replication:
The lettercasing used for displaying UUIDs in global transaction
identifiers was inconsistent. Now, all GTID values use
lowercase, including those shown in the
Executed_Gtid_Set columns from the output of
SHOW SLAVE STATUS.
InnoDB: When the primary key of a table includes a column prefix, and a full-text index is defined on the table, a full-text search resulted in an unnecessary warning being written to the error log. This fix suppresses the unnecessary warning. (Bug #16169411)
Adding or dropping a column.
Adding or dropping a primary key index.
Making a column
(Bug #16095573, Bug #68019)
During an online DDL
operation, changing a column from nullable to
NULL could succeed or fail differently depending on
ALTER TABLE statement
ALGORITHM=COPY. An operation with
ALGORITHM=COPY would succeed even if the
NULL values, while an
ALGORITHM=INPLACE would fail
because of the possibility that the column contained
NULL values. Now, making a column
NOT NULL in combination with the
ALGORITHM=INPLACE clause is allowed, but only
option includes the
ALGORITHM clause is not specified with
ALTER TABLE statement, the
online DDL operation will use
ALGORITHM=INPLACE if possible, or
ALGORITHM=COPY if not.
Under certain circumstances, an
was reported as corrupted after import using
TABLE ... IMPORT TABLESPACE. The problem was
accompanied by one of these messages:
Warning : InnoDB: The B-tree of index "PRIMARY" is corrupted. error : Corrupt
Warning : InnoDB: The B-tree of index "GEN_CLUST_INDEX" is corrupted. error : Corrupt
This issue occurred intermittently, and primarily affected large
TABLE statement would fix the problem reported by the
(Bug #15960850, Bug #67807)
Some Valgrind warnings were issued during shutdown, while
cleaning up a background thread that handles optimization of
During an online DDL
operation to add a
DML operations that created
duplicate values could fail with an
ER_DUP_KEY error even though the
index had not been made visible yet. (There was a brief time
window when this condition could occur.) The fix causes the
index creation operation to fail instead, if the index would be
invalid because of duplicate entries produced by concurrent DML.
If an online DDL operation to add a unique index failed, because
duplicate items were created by concurrent DML during the online
DDL operation, the
operation failed with the wrong error type. It returned
it returns the new error code
(It does not return
because the duplicate key value is not available to be reported
when this condition occurs.)
Names of indexes being created by an
online DDL operation were
being displayed incorrectly in
INFORMATION_SCHEMA tables while the operation
was in progress. This fix ensures the table names have the
0xff byte stripped off for
INFORMATION_SCHEMA queries. This change
affects the columns:
The status variable
could show an inaccurate value, higher than expected, because
some pages in the buffer
pool were incorrectly considered as being brought in by
(Bug #15859402, Bug #67476)
Creating an index on a
column could fail for a table with a character set with varying
length, such as
UTF-8, if the table was
created with the
innodb_log_file_size value of
4GB or larger was not possible on 64-bit Windows systems. This
issue only affected debug builds.
This fix ensures that in case of a serious unhandled error
operation that copies the original table, any data that could be
needed for data recovery is preserved, in tables using names of
This fix suspends the background
purge operation while a table
is being rebuilt by an
TABLE statement, if any rows containing
would be removed. Currently, to avoid excessive space usage
during the online DDL operation, avoid these types of concurrent
DML operations until the
ALTER TABLE is
InnoDB: The server could halt with an assertion error when creating an index on a column prefix for a column using a multibyte character set:
InnoDB: Assertion failure in thread
thread_numin file row0merge.cc line 465 InnoDB: Failing assertion: len == ifield-<fixed_len
InnoDB: The server could halt with an assertion error while creating an index:
InnoDB: Assertion failure in thread
thread_numin file row0merge.cc line 465
InnoDB: A regression introduced by the fix for Bug#14100254 would result in a “!BPAGE->FILE_PAGE_WAS_FREED” assertion. (Bug #14676249)
INFORMATION_SCHEMA tables with
InnoDB metadata, such as
nonalphanumeric characters in the names of tables using an
encoded format, for example with
If the value of
innodb_force_recovery was less
than 6, opening a corrupted table might loop forever if a
corrupted page was read when calculating statistics for the
table. Information about the corrupted page was written
repeatedly to the error log, possibly causing a disk space
issue. The fix causes the server to halt after a fixed number of
failed attempts to read the page. To troubleshoot such a
corruption issue, set
(Bug #14147491, Bug #65469)
Corruption of the
innodb_ft_user_stopword_table table could
cause a server exit.
(Bug #67960, Bug #16038656)
Partition pruning is now enabled for tables using a storage
engine that provides automatic partitioning, such as the
NDB storage engine, but which are
explicitly partitioned. Previously, pruning was disabled for all
tables using such a storage engine, whether or not the tables
had explicitly defined partitions.
In addition, as part of this fix, explicit partition selection
is now disabled for tables using a storage engine (such as
NDB) that provides automatic partitioning.
References: See also Bug #14672885.
Replication: When using GTID-based replication, and whenever a transaction was executed on the master but was not sent to the slave because the slave already had a transaction with that ID, semisynchrononous replication timed out. One case in which this could happen was during a failover operation where the new master started behind the new slave. (Bug #15985893)
An unnecessary flush to disk performed after every transaction
FILE as the replication info
repository type could degrade performance. Now this is done only
when both data and relay log info is stored in (transactional)
UNTIL SQL_BEFORE_GTIDS =
gtid_set covered a large number (tens
or hundreds of millions) of transactions, could cause the server
When a slave was started using
and replication info file repositories (
being the default for both
replication was incorrectly stopped. However, if the slave is
using file repositories and not currently migrating between info
repositories, replication should be able to work without issues.
Now the server ignores errors raised when trying to open table
info repositories in such conditions.
In addition, binary log initialization was not performed
correctly when starting the slave with
--skip-innodb, which caused the
--log-bin option to be ignored.
(Bug #15956714, Bug #67798, Bug #15971607)
When temporary and persistent tables, or temporary tables using
different storage engines, are dropped in a single statement,
this statement is actually written as two statements to the
binary log, each represented by its own log event. When
ON, each DDL event must have a GTID; however,
in such cases, the statement dropping the temporary table was
uncommitted, which meant that it was not given its own GTID.
Now, when a DDL statement dropping a temporary table and a table that is persistent, or that uses a different storage engine, is separated in the manner just described, and the resulting logged statement affecting only the temporary table does not implicitly commit, a commit is forced so that the corresponding log event has own unique GTID. (Bug #15947962)
When used on a binary log that had been written by a
GTID-enabled server, mysqlbinlog did not
correctly handle transactions left unclosed by the omission of
statements that were ignored when the
--database option was
Now, whenever mysqlbinlog
--database reads a GTID log
event, it checks to see whether there is an unclosed
transaction, and if so, issues a commit.
Replication: Semisynchronous replication did not work correctly with GTIDs enabled. (Bug #15927032)
References: See also Bug #14737388.
When GTIDs were enabled, the automatic dropping of a temporary
table when a client disconnected did not always generate a GTID.
Now each logged
statement, including any generated by the server, is guaranteed
to have its own GTID.
Replication: After dropping a column from the slave's version of a table, then altering the same column of this table on the master (so that a type conversion would have been required had the column not been droppped on the slave), inserts into this table caused replication to fail. (Bug #15888454)
is not compatible with GTID-based replication. Setting this
variable to a nonzero value is now disallowed whenever
--gtid-mode = ON, and attempting
to do so fails with an error.
When a binary log is replayed on a server (for example, by
executing a command like mysqlbinlog
mysql), it sets a pseudo-slave mode on the
client connection used, so that the server can read binlog and
apply binary log events correctly. However, the pseudo-slave
mode was not disabled after the binary log dump was read, which
caused unexpected filtering rules to be applied to SQL
statements subsequently executed on the same connection.
Replication: During mysqld shutdown, global GTID variables were released before it was made certain that all plugins had stopped using them. (Bug #14798275)
MASTER_POS_WAIT() could hang or
return -1 due to invalid updates by the slave SQL thread when
transactions were skipped by the GTID protocol.
References: See also Bug #15927032.
Replication: Trying to execute a Stop event on a multithreaded slave could cause unwanted updates to the relay log, leading the slave to lose synchronization with the master. (Bug #14737388)
Replication: Names of databases in binary log query log events were not properly checked for length. (Bug #14636219)
When using statement-based replication, and where the master and
the slave used table schemas having different
AUTO_INCREMENT columns, inserts generating
AUTO_INCREMENT values logged for a given
table on the master could be applied to the wrong table on the
Repeated execution of
TO statements using invalid
MASTER_LOG_POS values could lead to errors
and possibly a crash on the slave. Now in such cases, the
statement fails with a clear error message.
(Bug #11764602, Bug #57454)
Microsoft Windows: Dynamic file names (with colons) are no longer allowed. Static file names using the Alternate Data Stream (ADS) NTFS functionality of Microsoft Windows may continue to be used. (Bug #11761752)
Oracle RPM packages were unusable by
to issues with the
obsoletes line in the
.spec file causing yum
to interpret the package as obsoleting itself.
During client connection processing, the server now performs password-expiration checking after SSL checks. (Bug #16103348)
A buffer-handling problem in yaSSL was fixed. (Bug #15965288)
The plugin logging routine mishandled its argument, resulting in undefined behavior. (Bug #16002890)
An online DDL operation that dropped an index could proceed despite not having sufficient locks on the table. This issue could cause a serious error, although the error was only observed in debug builds. (Bug #15936065)
ALTER TABLE with the
ADD PRIMARY KEY or
INDEX clause could encounter a serious error if the
columns for the primary
key or unique
index contained duplicate entries. This error occurred
intermittently, depending on how the rows were physically
distributed across index blocks.
In certain rare cases, a query using
UpdateXML() could cause the
server to crash.
References: See also Bug #13007062.
Several OpenSSL-related Valgrind warnings were corrected. (Bug #15908967)
Several OpenSSL-related memory leaks were fixed. (Bug #15921729)
Very long database names in queries could cause the server to exit. (Bug #15912213)
Within a stored procedure, executing a multiple-table
DELETE statement that used a very
long table alias could cause the server to exit.
Very long table aliases in queries could cause the server to exit. (Bug #15948123)
Metadata locking and table definition cache routines did not always check length of names passed to them. (Bug #15954872)
A comment added to mysqldump output for the
--set-gtid-purged option was
malformed and caused a syntax error when the dump file was
References: See also Bug #14832472.
Contention in the thread pool during kill processing could lead to a Valgrind panic. (Bug #15921866)
If an error occurred during the final phase of an
online DDL operation,
some cached metadata about the table might not be restored to
its original state. This issue typically affected operations
that renamed a column, and also dropped and re-created an index
on that column, in the same
TABLE statement. This issue did not affect operations
that reorganize the
index of the table, such as adding a new primary key.
In debug builds, the server could not start on 64-bit Windows
systems when a value of 16 GB or higher was specified for
Non-debug builds would likely have subtler issues, such as
memory being allocated for the
buffer pool but not
used, or read requests overlooking pages already cached in the
On 32-bit Windows systems, the value of
increased if necessary so that no buffer pool instance is larger
then 1.3 GB, due to system limitations on memory allocation.
This automatic adjustment needed for 32-bit Windows systems was
incorrectly applied to 64-bit systems also; for systems with 16
GB or larger buffer pools, the adjusted value of
innodb_buffer_pool_instances would exceed the
upper limit of 64, causing an assertion error in debug builds.
A heavy workload of online
DDL and concurrent DML on
a table on a master
server could cause errors as the changes were replicated
servers. For example, processing a
COLUMN operation at the same time as queries referring
to the dropped column could cause errors on slave servers if the
statements finished in a different order than on the master.
If the server shut down unexpectedly, the presence of an
InnoDB table with 1018 columns (very close to
the upper limit of 1020 columns) could cause an assertion error
during server restart:
InnoDB: Failing assertion: table->n_def == table->n_cols - 3
The Performance Schema normally ignores temporary table events. User-defined temporary tables are truncated by being re-created, but the Performance Schema did not recognize re-created temporary tables as being temporary and raised an assertion. (Bug #15884836)
The Performance Schema
displayed extraneous information.
COUNT(DISTINCT ...)) could
cause the server to exit.
References: See also Bug #11750963.
Rows_log_event allocated one too few bytes
for the row buffer.
For the LooseScan semi-join strategy, the optimizer could rely on an uninitialized variable. (Bug #15849654)
For debug builds, an assertion could be raised when: 1) A view
was based on a
table; 2) The table was altered to drop some column in use by
the view; 3) A
SELECT was done on
the view with binary logging disabled.
If loose index scan was used on a query with descending order,
the result set contained
NULL values instead
of the correct values.
The optimizer's cost-based choice between
EXISTS subquery transformation and subquery
materialization was sometimes incorrect if the
IN predicate was
with some other predicate.
References: See also Bug #13111584.
In some cases, a cost value was printed to Optimizer Trace output without being initialized, resulting in incorrect output. (Bug #15877453)
Several code issues identified by Fortify were corrected. (Bug #15884324)
Some queries, if used as prepared statements, caused the server to exit if an error occurred. (Bug #15877062)
IN subqueries could cause the server
It was possible to expire the password for an account even if the account is authenticated by an authentication plugin that does not support password expiration. (Bug #15849009)
When the server reads the
it now checks for invalid native and old-native password hashes
and ignores accounts with invalid hashes.
validate_password plugin did not check
GRANT ... IDENTIFIED
BY could fail to flush the privileges.
variable did not take into account that the minimum value is a
function of several other related system variables. Now the
server will not set the value less than the value of this
validate_password_number_count + validate_password_special_char_count + (2 * validate_password_mixed_case_count)
An issue with locking order for the system tables and the InnoDB data dictionary could lead to an internal deadlock within MySQL. (Bug #14805484)
When used with an XPath expression that contained the output of
a stored function,
failed with the error Only constant XPATH queries are
(Bug #14798445, Bug #67313)
MySQL could encounter an error during shutdown on Windows XP or earlier systems. This issue did not affect systems running Windows Vista or higher, which use atomic condition variables to represent Windows Events. (Bug #14822849)
Temporary table creation during execution of
INFORMATION_SCHEMA queries could result in
mysqladmin did not properly process commands for users with expired passwords. (Bug #14833621)
XA START had a
race condition that could cause a server crash.
ALGORITHM=INPLACE clause in an
ALTER TABLE statement for a
partitioned table could lead to consistency issues if a crash
occurred while changes were applied to some of the underlying
tables but not all. This fix prohibits the
ALGORITHM=INPLACE clause for DDL operations
on partitioned tables.
The server could halt with an assertion error due to a recently added error code:
InnoDB: unknown error code 1502 InnoDB: Assertion failure in thread
thread_numin file row0mysql.cc line 683 mysqld got signal 6 ;
Now, the server returns the error code
DB_DICT_CHANGED to the client in this case.
Queries that used grouping failed when executed using a cursor if the optimizer processed the grouping using a temporary table. (Bug #14740889)
sha256_password authentication plugin
requires that the client connect either using SSL or have RSA
enabled. When neither condition was met, an uninformative error
message was produced. Now the error message is more informative.
The server now logs warnings at startup if the file specified
system variable violates constraints on valid password file
Output generated with mysqldump --routines could produce syntax errors when reloaded. (Bug #14463669)
Calculations involving self-intersecting polygons caused an assertion to be raised. (Bug #14503584)
ALTER TABLE was killed, the server could
even if the alterations had been made successfully. This is
misleading to the user. Also, the statement would not be written
to the binary log, leading to incorrect replication
The parser failed to return an error for some invalid
Preloading of client plugins specified with the
LIBMYSQL_PLUGINS environment variable could
fail unless the plugins were located in the hardwired default
plugin directory. The C API now checks during plugin preloading
variable which can be set to the path name of the directory in
which to look for client plugins.
In addition, for explicit client plugin loading, the
mysql_load_plugin_v() C API
functions have been modified to use the
LIBMYSQL_PLUGIN_DIR value if it exists and
--plugin-dir option was not given. If
--plugin-dir is given,
SQL mode enabled, executing a stored function twice that
contains a SQL query that is not valid with that mode enabled
caused the server to exit.
Autosizing of Performance Schema parameters could result in settings that caused excessive CPU use. (Bug #67736, Bug #15927744)
The optimizer sometimes chose a nonoptimimal range scan strategy
when a query included a
(Bug #67432, Bug #15829358)
Full-text searches in
could return incorrect results.
(Bug #67257, Bug #14771282)
The mysql client could mishandle the
delimiter command if it occurred on a line
mysql was looking for the end of
a quoted string.
(Bug #64135, Bug #13639125)
The Performance Schema normally ignores temporary table events, but sometimes failed to properly identify a table as temporary and consequently recorded events for the table. (Bug #67098, Bug #14756887)
Some messages written by the server to the error log referred to
--log-slow-queries option rather
--slow-query-log option. Similarly,
the server referred to the deprecated
option rather than the
(Bug #67892, Bug #15996571)
Attempting to perform an in-place upgrade from MySQL 5.1 to 5.6 causes the server to exit due to a mismatch between the privilege structures in the two series. (This is not a supported operation, but the server should not exit ungracefully.) (Bug #67319, Bug #14826854)
DECIMAL multiplication operations could
produce significant inaccuracy.
(Bug #45860, Bug #11754279)
Due to a thread race condition, the server could exit while
attempting to read the Performance Schema
(Bug #68127, Bug #16196158)
The optimizer could choose an
transformation for subquery execution in some cases when
subquery materialization would be cheaper.
(Bug #67511, Bug #15848521)
It is not permitted to use
TABLE to create an
NDB table with
user-defined partitioning and a foreign key. However, it was
possible to create an
NDB table with a
foreign key, then add partitioning to it using
ALTER TABLE, thus creating a
table which was impossible to back up or restore using
mysqldump. Now the prohibition is enforced
(Bug #67492, Bug #15844519)
EXPLAIN displayed a
type value of
(full-table scan access method) even if the optimizer chose to
scan the table by an index access method. Now the
type value is displayed as
(Bug #67637, Bug #15892875)
mysqldump could fail to dump all tables in
(Bug #67261, Bug #14771252)