This is a milestone release, for use at your own risk. Upgrades between milestone releases (or from a milestone release to a GA release) are not supported. 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. (Making a backup before the upgrade is a prudent precaution in any case.)
The Performance Schema has these additions:
setup_consumerstable 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_objectstable. 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 table,
objects_summary_global_by_type, 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
threadstable, which contains a row for each active server thread, was extended with several new columns. With these additions, the information available in
threadsis like that available from the
INFORMATION_SCHEMA.PROCESSLISTtable or the output from
SHOW PROCESSLIST. Thus, all three serve to provide information for thread-monitoring purposes. Use of
threadsdiffers from use of the other two thread information sources in these ways:
threadsdoes not require a mutex and has minimal impact on server performance.
SHOW PROCESSLISThave negative performance consequences because they require a mutex.
threadsprovides 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 the
INSTRUMENTEDcolumn or by using the
If you upgrade to this MySQL release 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.
Incompatible Change: The following obsolete constructs have been removed. Where alternatives are shown, applications should be updated to use them.
--logserver option and the
logsystem variable. Instead, use the
--general_logoption to enable the general query log and the
--general_log_file=option to set the general query log file name.
--log-slow-queriesserver option and the
log_slow_queriessystem variable. Instead, use the
--slow_query_logoption to enable the slow query log and the
--slow_query_log_file=option to set the slow query log file name.
sql_big_tablessystem variable. Use
sql_low_priority_updatessystem variable. Use
sql_max_join_sizesystem variable. Use
ONE_SHOTmodifier for the
Important Change; Replication: Replication filtering options such as
--replicate-do-tablewere not consistent with one another in regard to case sensitivity. Now all
--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
lower_case_table_namessystem variable. (Bug #51639, Bug #11759334)
Important Change; Replication: Added the
MASTER_RETRY_COUNToption to the
CHANGE MASTER TOstatement, and a corresponding
Master_Retry_Countcolumn to the output of
SHOW SLAVE STATUS. The option sets the value shown in this column.
MASTER_RETRY_COUNTis intended eventually to replace the older (and now deprecated)
--master-retry-countserver 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)
0disables read-ahead. Prior to 5.6.1, a value of
0would trigger a read-ahead upon reading the boundary page of a 64 page extent. (Bug #11763876, Bug #56646)
InnoDBcan now report the total size of the rollback segment, measured in pages. The value is reported through the
information_schema.innodb_metricstable, using the counter
trx_rseg_current_size. You enable and query the counter as follows:
mysql> SET GLOBAL innodb_monitor_enable = 'trx_rseg_current_size'; mysql> SELECT name, count, max_count, comment -> FROM innodb_metrics WHERE name = 'trx_rseg_current_size'; +-----------------------+-------+-----------+----------------------------------------+ | name | count | max_count | comment | +-----------------------+-------+-----------+----------------------------------------+ | trx_rseg_current_size | 346 | 346 | Current rollback segment size in pages | +-----------------------+-------+-----------+----------------------------------------+
SHOW SLAVE STATUSnow displays the actual number of retries for each connection attempt made by the I/O thread. (Bug #56416, Bug #11763675)
Replication: Timestamps have been added to the output of
SHOW SLAVE STATUSto show when the most recent I/O and SQL thread errors occurred. The
Last_IO_Errorcolumn is now prefixed with the timestamp for the most recent I/O error, and
Last_SQL_Errorshows the timestamp for the most recent SQL thread error. The timestamp values use the format
YYMMDD HH:MM:SSin 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)
EXPLAINoutput for a large union truncated the
UNION RESULTrow 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 following items are deprecated and will be removed in a future MySQL release. Where alternatives are shown, applications should be updated to use them.
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 produced.
For collations that require tailoring rules, there is no longer a fixed size limit on the tailoring information.
The Unicode implementation has been extended to include a
utf16lecharacter set, which corresponds to the UTF-16LE encoding of the Unicode character set. This is similar to
utf16(UTF-16) but is little-endian rather than big-endian.
utf16lecollations 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 limitations on
utf16lecannot be used as a client character set, which means that it also does not work for
SET CHARACTER SET.
It is not possible to use
LOAD DATAto load data files that use
FULLTEXTindexes cannot be created on a column that uses
utf16le. However, you can perform
IN BOOLEAN MODEsearches on the column without an index.
The use of
utf16leis not recommended because the underlying system call expects a string terminated by a zero byte.
It is not possible to create user-defined UCA collations for
utf16lebecause there is no
utf16le_unicode_cicollation, which would serve as the basis for such collations.
Changes to replication in MySQL 5.6 make mysqlbinlog output generated by the
ALWAYSis 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.
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.
Several changes were made to optimizer-related system variables:
optimizer_switchsystem variable has new
index_condition_pushdownflags to control whether storage engine condition pushdown and index condition pushdown optimizations are used. The
engine_condition_pushdownsystem variable now is deprecated. For information about condition pushdown, see Engine Condition Pushdown Optimization, and Index Condition Pushdown Optimization.
optimizer_switchsystem variable has new
mrr_cost_basedflags to control use of the Multi-Range Read optimization. The
optimizer_use_mrrsystem 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,
optimizer_join_cache_level, controls how join buffering is done.
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 rectangles, whereas
ST_Contains()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
In addition, the
ST_Distance()spatial functions are now implemented, as well as the set operator functions
ST_Union(), (Bug #4249, Bug #11744883)
--bind-addressoption has been added to a number of MySQL client programs: mysql, mysqldump, mysqladmin, mysqlbinlog, mysqlcheck, mysqlimport, 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_BINDoption for specifying the interface. The argument is a host name or IP address (specified as a string).
Incompatible Change; Replication: The behavior of
INSERT DELAYEDstatements when using statement-based replication has changed as follows:
INSERT DELAYEDcontinues to be executed as
DELAYEDoption). The behavior of
INSERT DELAYEDremains unchanged when using
INSERT DELAYEDgenerates no warnings, is executed as
INSERT DELAYED, and is logged using the row-based format.
This change also affects
INSERT DELAYEDis 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
DELAYEDoption), using the statement-based logging format. (Bug #54579, Bug #11762035)
References: See also: Bug #56678, Bug #11763907, Bug #57666. This issue is a regression of: Bug #39934, Bug #11749859.
Incompatible Change; Replication: When determining whether to replicate a
DROP DATABASE, or
ALTER DATABASEstatement, database-level options now take precedence over any
--replicate-wild-do-tableoptions. In other words, when trying to replicate one of these statements,
--replicate-wild-do-tableoptions are now checked if and only if there are no database-level options that apply to the statement. (Bug #46110, Bug #11754498)
Incompatible Change: Starvation of
FLUSH TABLES WITH READ LOCKstatements 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
HANDLERstatement tried to update data through a DML statement while another connection tried to execute
FLUSH TABLES WITH READ LOCKconcurrently.
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
LOCK_event_metadatamutex was replaced with metadata locks on events. As a result, DDL operations on events are now prohibited under
LOCK TABLES. This is an incompatible change.
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 LOCKare 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 lockis replaced by
Waiting for global read lock.
Waiting for release of readlockwas used to indicate that DML/DDL statements were waiting for release of a read lock and
Waiting to get readlockwas used to indicate that
FLUSH TABLES WITH READ LOCKwas waiting to acquire a global read lock. Now
Waiting for global read lockis used for both cases.
Waiting for release of readlockwas 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 finishwas used by
FLUSH TABLES WITH READ LOCK. Now
Waiting for commit lockis used for both cases.
There are two other new states,
Waiting for trigger metadata lockand
Waiting for event metadata lock.
(Bug #57006, Bug #11764195, Bug #54673, Bug #11762116)
One consequence of this change is that
CREATE TABLE ... LIKEmakes the same checks as
CREATE TABLEand does not just copy the
.frmfile. 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)
InnoDB; Replication: If the master had
innodb_strict_mode=OFF), or both, certain
CREATE TABLEoptions, such as
KEY_BLOCK_SIZE, were ignored. This could permit the master to avoid raising
However, the ignored
CREATE TABLEoptions were still written into the binary log, so that, if the slave had
innodb_file_format=Barracuda, it could encounter an
ER_TOO_BIG_ROWSIZEerror 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_formatare reverted to the MySQL 5.1 default values—that is,
Antelope, respectively. (Bug #56318, Bug #11763590)
InnoDB: If the MySQL Server crashed immediately after creating an
InnoDBtable, the server could quit with a
signal 11during the subsequent restart. The issue could occur if the server halted after
InnoDBcreated the primary index for the table, but before the index definition was recorded in the MySQL metadata. (Bug #57616)
References: This issue is a regression of: Bug #54582.
InnoDB: With binary logging enabled,
InnoDBcould halt during crash recovery with a message referring to a transaction ID of 0. (Bug #54901, Bug #11762323)
Replication: Due to changes made in MySQL 5.5.3, settings made in the
max_binlog_cache_sizeserver 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
max_binlog_stmt_cache_size, which affect only the binary log statement cache.
In addition, the
Binlog_cache_usestatus variable was incremented whenever either cache was used, and
Binlog_cache_disk_usewas 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
Binlog_stmt_cache_disk_use, which are incremented only by usage of the binary log statement cache.
The behavior of the
max_binlog_cache_sizesystem variable with regard to active sessions has also been changed to match that of the
binlog_cache_sizesystem variable: Previously, a change in
max_binlog_cache_sizetook effect in existing sessions; now, as with a change in
binlog_cache_size, a change in
max_binlog_cache_sizetakes effect only in sessions begun after the value was changed.
References: This issue is a regression of: Bug #50038.
STOP SLAVEis 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
CREATE TEMPORARY TABLEstatements,
DROP TEMPORARY TABLEstatements, 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 SLAVEstatement, 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 case).
Following this fix, if an ongoing transaction contains
CREATE TEMPORARY TABLEstatements,
DROP TEMPORARY TABLEstatements, 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.
lower_case_table_nameswas 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_namesset to 1 on the slave only, names of tables were also not converted, also causing replication failure on slaves using case-sensitive file systems. (Bug #37656)
collation_connectionto one of the collations for the
utf16character sets, it was not possible to change the collation thereafter. (Bug #65000, Bug #13970475)
A Valgrind failure occurred in
fn_formatwhen called from
archive_discover. (Bug #58205, Bug #11765259)
In bootstrap mode, the server could not execute statements longer than 10,000 characters. (Bug #55817, Bug #11763139)
NULLvalues were not grouped properly for some joins containing
GROUP BY. (Bug #45267, Bug #11753766)
HAVINGclause could be lost if an index for
ORDER BYwas 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 BYqueries against
InnoDBtables. (Bug #37977, Bug #11749031)
An incorrectly checked
XORsubquery 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,
InnoDBcould 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 semi-join
INsubqueries, 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
FROMclause and an
INclause caused a server crash. (Bug #33245)
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 indexed
DECIMALcolumn with a string value. (Bug #32262, Bug #11747426)
The server crashed on optimizations that used the
range checked for each recordaccess method. (Bug #32229, Bug #11747417)
Contains()failed for multipolygon geometries. (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
LIMITqueries, failure to close the scan caused file descriptor leaks for
MyISAMtables. (Bug #30221, Bug #11746994)