This is a milestone release, for use at your own risk. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward.
Performance Schema Notes
The Performance Schema has these additions:
contents have changed. Previously, the table used a
“flat” structure with a one-to-one
correspondence between consumer name and destination table.
This has been replaced with a hierarchy of consumer settings
that enable progressively finer control of which
destinations receive events. The previous
consumers no longer exist. Instead, the Performance Schema
maintains appropriate summaries automatically for the levels
for which settings in the consumer hierarchy are enabled.
For example, if only the top-level (global) consumer is
enabled, only global summaries are maintained. Others, such
as thread-level summaries, are not. See
Pre-Filtering by Consumer. In
addition, optimizations have been added to reduce
Performance Schema overhead.
It is now possible to filter events by object using the new
setup_objects table. Currently,
this table can be used to selectively instrument tables,
based on schema names and/or table names. See
Pre-Filtering by Object. A new
summarizes events for objects.
It is now possible to filter events by thread, and the
Performance Schema collects more information for each
thread. A new table,
setup_actors, can be used to
selectively instrument user connections, based on the user
name and/or host name of each connecting session. The
threads table, which contains a
row for each active server thread, was extended with several
new columns. With these additions, the information available
threads is like that
available from the
table or the output from
PROCESSLIST. Thus, all three serve to provide
information for thread-monitoring purposes. Use of
threads differs from use of the
other two thread information sources in these ways:
threads does not
require a mutex and has minimal impact on server
SHOW PROCESSLIST have
negative performance consequences because they require a
threads provides additional
information for each thread, such as whether it is a
foreground or background thread, and the location within
the server associated with the thread.
You can control which threads are monitored by setting
INSTRUMENTED column or by using
If you upgrade to this release of MySQL from an earlier version,
you must run mysql_upgrade (and restart the
server) to incorporate these changes into the
For more information, see MySQL Performance Schema.
Functionality Added or Changed
Incompatible Change: The following obsolete constructs have been removed. Where alternatives are shown, applications should be updated to use them.
--log server option and
log system variable.
Instead, use the
--general_log option to
enable the general query log and the
option to set the general query log file name.
option and the
variable. Instead, use the
--slow_query_log option to
enable the slow query log and the
option to set the slow query log file name.
sql_big_tables system variable. Use
sql_max_join_size system variable.
ONE_SHOT modifier for the
Important Change; Replication:
Replication filtering options such as
--replicate-do-table were not
consistent with one another in regard to case sensitivity. Now
--replicate-* options follow the same rules
for case sensitivity applying to names of databases and tables
elsewhere in the MySQL server, including the effects of the
(Bug #51639, Bug #11759334)
Important Change; Replication:
MASTER_RETRY_COUNT option to the
CHANGE MASTER TO statement, and a
Master_Retry_Count column to
the output of
SHOW SLAVE STATUS.
The option sets the value shown in this column.
MASTER_RETRY_COUNT is intended eventually to
replace the older (and now deprecated)
option, and is now the preferred method for setting the maximum
number of times that the slave may attempt to reconnect after
losing its connection to the master.
(Bug #44209, Bug #11752887, Bug #44486, Bug #11753110)
0 disables read-ahead. Prior to 5.6.1, a
0 would trigger a read-ahead upon
reading the boundary page of a 64 page extent.
(Bug #11763876, Bug #56646)
InnoDB can now report the total size of the
measured in pages. The value is
reported through the
table, using the counter
trx_rseg_curent_size. You enable and query
the counter as follows:
mysql (information_schema) > set global innodb_monitor_enable = 'trx_rseg_curent_size'; mysql (information_schema) > select name, count, max_count, comment from innodb_metrics where name = 'trx_rseg_curent_size'; +----------------------+-------+-----------+----------------------------------------+ | name | count | max_count | comment | +----------------------+-------+-----------+----------------------------------------+ | trx_rseg_curent_size | 346 | 346 | Current rollback segment size in pages | +----------------------+-------+-----------+----------------------------------------+
SHOW SLAVE STATUS now displays
the actual number of retries for each connection attempt made by
the I/O thread.
(Bug #56416, Bug #11763675)
Timestamps have been added to the output of
SHOW SLAVE STATUS to show when
the most recent I/O and SQL thread errors occurred. The
Last_IO_Error column is now prefixed with the
timestamp for the most recent I/O error, and
Last_SQL_Error shows the timestamp for the
most recent SQL thread error. The timestamp values use the
YYMMDD HH:MM:SS in both of these
columns. For more information, see
SHOW SLAVE STATUS Syntax.
(Bug #43535, Bug #11752361, Bug #64255, Bug #13726435)
“Unknown table” error messages that included only the table name now include the database name as well. (Bug #34750, Bug #11747993)
EXPLAIN output for a
large union truncated the
UNION RESULT row at
the end of the list as follows if the string became too large:
To make it easier to understand the union boundaries, truncation now occurs in the middle of the string:
(Bug #30597, Bug #11747073)
The OpenGIS specification defines functions that test the
relationship between two geometry values. MySQL originally
implemented these functions such that they used object bounding
rectangles and returned the same result as the corresponding
MBR-based functions. Corresponding versions are now available
that use precise object shapes. These versions are named with an
ST_ prefix. For example,
Contains() uses object bounding
uses object shapes. For more information, see
Functions That Test Spatial Relations Between Geometry Objects.
There are also now
ST_ aliases for existing
spatial functions that were already exact. For example,
ST_IsEmpty() is an alias for
Croatian collations were added for Unicode character sets:
utf32_croatian_ci. Thee collations have
tailoring for Croatian letters:
Ž. They are based on Unicode 4.0.
The Unicode implementation has been extended to include a
utf16le character set, which corresponds to
the UTF-16LE encoding of the Unicode character set. This is
utf16 (UTF-16) but is
little-endian rather than big-endian.
utf16le collations are available:
utf16le_general_ci: The default
collation, case sensitive (similar to
utf16le_bin: Case sensitive, with
by-codepoint comparison that provides the same order as
There are some limitations on the use of
utf16le. With the exception of the item
regarding user-defined collations, these are the same as the
utf16le cannot be used as a client
character set, which means that it also does not work for
SET NAMES or
It is not possible to use
INFILE to load data files that use
FULLTEXT indexes cannot be created on a
column that uses
utf16le. However, you
IN BOOLEAN MODE searches on
the column without an index.
The use of
utf16le is not recommended because the
underlying system call expects a string terminated by a zero
It is not possible to create user-defined UCA collations for
utf16le because there is no
utf16le_unicode_ci collation, which would
serve as the basis for such collations.
--bind-address option has been
added to a number of MySQL client programs:
and mysqlshow. This is for use on a computer
having multiple network interfaces, and enables you to choose
which interface is used to connect to the MySQL server.
A corresponding change was made to the
mysql_options() C API function,
which now has a
MYSQL_OPT_BIND option for
specifying the interface. The argument is a host name or IP
address (specified as a string).
Changes to replication in MySQL 5.6 make
mysqlbinlog output generated by the
ALWAYS is now an invalid
value for this option. If the option is given without a value,
the effect is now the same as
References: See also Bug #28760.
Support for adding Unicode collations that are based on the Unicode Collation Algorithm (UCA) has been improved:
MySQL now recognizes a larger subset of the LDML syntax that
is used to write collation descriptions. In many cases, it
is possible to download a collation definition from the
Unicode Common Locale Data Repository and paste the relevant
part (that is, the part between the
</rules> tags) into the MySQL
Character representation in LDML rules is more flexible. Any character can be written literally, not just basic Latin letters. For collations based on UCA 5.2.0, hexadecimal notation can be used for any character, not just BMP characters.
When problems are found while parsing
Index.xml, better diagnostics are
For collations that require tailoring rules, there is no longer a fixed size limit on the tailoring information.
Several changes were made to optimizer-related system variables:
variable has new
index_condition_pushdown flags to control
whether storage engine condition pushdown and index
condition pushdown optimizations are used. The
system variable now is deprecated. For information about
condition pushdown, see
Engine Condition Pushdown Optimization, and
Index Condition Pushdown Optimization.
variable has new
mrr_cost_based flags to control use of
the Multi-Range Read optimization. The
optimizer_use_mrr system variable has
been removed. For information about Multi-Range Read, see
Multi-Range Read Optimization.
The Block Nested-Loop (BNL) Join algorithm previously used only for inner joins has been extended and can be employed for outer join operations, including nested outer joins. For more information, see Block Nested-Loop and Batched Key Access Joins.
In conjunction with this work, a new system variable,
controls how join buffering is done.
The following items are deprecated and will be removed in a future MySQL release. Where alternatives are shown, applications should be updated to use them.
Incompatible Change; Replication:
The behavior of
statements when using statement-based replication has changed as
INSERT DELAYED continues to be
INSERT (without the
DELAYED option). The behavior of
INSERT DELAYED remains unchanged
INSERT DELAYED generates no
warnings, is executed as
DELAYED, and is logged using the row-based format.
This change also affects
INSERT DELAYED is no longer
considered unsafe. Now, when the logging format is
MIXED, no switch to row-based logging occurs.
This means that the statement is logged as a simple
INSERT (that is, without the
DELAYED option), using the statement-based
(Bug #54579, Bug #11762035)
References: See also Bug #56678, Bug #11763907, Bug #57666. This bug was introduced by Bug #39934, Bug #11749859.
Incompatible Change; Replication:
When determining whether to replicate a
DROP DATABASE, or
ALTER DATABASE statement,
database-level options now take precedence over any
options. In other words, when trying to replicate one of these
are now checked if and only if there are no database-level
options that apply to the statement.
(Bug #46110, Bug #11754498)
TABLES WITH READ LOCK statements occurred when there
was a constant load of concurrent DML statements in two or more
connections. Deadlock occurred when a connection that had some
table open through a
statement tried to update data through a DML statement while
another connection tried to execute
FLUSH TABLES WITH READ
These problems resulted from the global read lock implementation, which was reimplemented with the following consequences:
To solve deadlock in event-handling code that was exposed by
this patch, the
was replaced with metadata locks on events. As a result, DDL
operations on events are now prohibited under
LOCK TABLES. This is an
The global read lock
FLUSH TABLES WITH
READ LOCK) no longer blocks DML and DDL on
temporary tables. Before this patch, server behavior was not
consistent in this respect: In some cases, DML/DDL
statements on temporary tables were blocked; in others, they
were not. Since the main use cases for
FLUSH TABLES WITH
READ LOCK are various forms of backups and
temporary tables are not preserved during backups, the
server now consistently permits DML/DDL on temporary tables
under the global read lock.
The set of thread states has changed:
Waiting for global metadata lock is
Waiting for global read
Waiting for release of
readlock was used to indicate that DML/DDL
statements were waiting for release of a read lock and
Waiting to get readlock was used to
FLUSH TABLES WITH
READ LOCK was waiting to acquire a global read
Waiting for global read
lock is used for both cases.
Waiting for release of
readlock was used for all statements that
caused an explicit or implicit commit to indicate that
they were waiting for release of a read lock and
Waiting for all running commits to
finish was used by
FLUSH TABLES WITH
READ LOCK. Now
Waiting for commit
lock is used for both cases.
There are two other new states,
trigger metadata lock and
event metadata lock.
(Bug #57006, Bug #11764195, Bug #54673, Bug #11762116)
One consequence of this change is that
CREATE TABLE ...
LIKE makes the same checks as
CREATE TABLE and does not just
.frm file. This means that if the
current SQL mode is different from the mode in effect when the
original table was created, the table definition might be
considered invalid for the new mode and the statement will fail.
(Bug #42546, Bug #11751609)
If the master had
or both, certain
options, such as
ignored. This could permit the master to avoid raising
However, the ignored
options were still written into the binary log, so that, if the
it could encounter an
ER_TOO_BIG_ROWSIZE error while
executing the record from the log, causing the slave SQL thread
to abort and replication to fail.
In the case where the master was running MySQL 5.1 and the slave
was MySQL 5.5 (or later), the failure occurred when both master
and slave were running with default values for
innodb_file_format. This could
cause problems during upgrades.
To address this issue, the default values for
innodb_file_format are reverted
to the MySQL 5.1 default values—that is,
(Bug #56318, Bug #11763590)
If the MySQL Server crashed immediately after creating an
InnoDB table, the server could quit with a
signal 11 during the subsequent restart. The
issue could occur if the server halted after
InnoDB created the primary index for the
table, but before the index definition was recorded in the MySQL
References: This bug is a regression of Bug #54582.
With binary logging enabled,
halt during crash recovery with a message referring to a
transaction ID of 0.
(Bug #54901, Bug #11762323)
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.
References: This bug is a regression of Bug #50038.
STOP SLAVE is issued, the
slave SQL thread rolls back the current transaction and stops
immediately if the transaction updates only tables which use
transactional storage engines. Previously, this occurred even
when the transaction contained
TABLE statements, or both, although these statements
cannot be rolled back. Because temporary tables persist for the
lifetime of a user session (in the case, the replication user),
they remain until the slave is stopped or reset. When the
transaction is restarted following a subsequent
START SLAVE statement, the SQL
thread aborts with an error that a temporary table to be created
(or dropped) already exists (or does not exist, in the latter
Following this fix, if an ongoing transaction contains
TABLE statements, or both, the SQL thread now waits
until the transaction ends, then stops.
(Bug #56118, Bug #11763416)
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.
set to 1 on the slave, but not on the master, names of databases
in replicated statements were not converted, causing replication
to fail on slaves using case-sensitive file systems. This
occurred for both statement-based and row-based replication.
In addition, when using row-based replication with
lower_case_table_names set to 1
on the slave only, names of tables were also not converted, also
causing replication failure on slaves using case-sensitive file
collation_connection to one of
the collations for the
utf16 character sets, it was not possible to
change the collation thereafter.
(Bug #65000, Bug #13970475)
A Valgrind failure occurred in
(Bug #58205, Bug #11765259)
In bootstrap mode, the server could not execute statements longer than 10,000 characters. (Bug #55817, Bug #11763139)
NULL values were not grouped properly for
some joins containing
(Bug #45267, Bug #11753766)
HAVING clause could be lost if an index for
ORDER BY was available, incorrectly
permitting additional rows to be returned.
(Bug #45227, Bug #11753730)
The optimizer could underestimate the memory required for column descriptors during join processing and cause memory corruption or a server crash. (Bug #42744, Bug #11751763)
The server returned incorrect results for
WHERE ... OR
... GROUP BY queries against
(Bug #37977, Bug #11749031)
An incorrectly checked
optimization resulted in an assertion failure.
(Bug #37899, Bug #11748998)
A query that could use one index to produce the desired ordering and another index for range access with index condition pushdown could cause a server crash. (Bug #37851, Bug #11748981)
With index condition pushdown enabled,
InnoDB could crash due to a
mismatch between what pushdown code expected to be in a record
versus what was actually there.
(Bug #36981, Bug #11748647)
The range optimizer ignored conditions on inner tables in
IN subqueries, causing the
optimizer to miss good query execution plans.
(Bug #35674, Bug #11748263)
A server crash or memory overrun could occur with a dependent subquery and joins. (Bug #34799, Bug #11748009)
Selecting from a view that referenced the same table in the
FROM clause and an
clause caused a server crash.
Deeply nested subqueries could cause stack overflow or a server crash. (Bug #32680, Bug #11747503)
The server crashed on optimization of queries that compared an
DECIMAL column with a
(Bug #32262, Bug #11747426)
The server crashed on optimizations that used the
checked for each record access method.
(Bug #32229, Bug #11747417)
Contains() failed for
(Bug #32032, Bug #11747370)
Compared to MySQL 5.1, the optimizer failed to use join buffering for certain queries, resulting in slower performance for those queries. (Bug #30363, Bug #11747028)
For Multi-Range Read scans used to resolve
LIMIT queries, failure to close the scan
caused file descriptor leaks for
(Bug #30221, Bug #11746994)