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.)
Incompatible Change: MySQL now supports the
GET DIAGNOSTICSprovides applications a standardized way to obtain information from the diagnostics area, such as whether the previous SQL statement produced an exception and what it was. See GET DIAGNOSTICS Statement.
In addition, several deficiencies in condition handler processing rules were corrected so that MySQL behavior is more like standard SQL:
Block scope is used in determining which handler to select. Previously, a stored program was treated as having a single scope for handler selection.
Condition precedence is more accurately resolved.
Diagnostics area clearing has changed. Bug #55843 caused handled conditions to be cleared from the diagnostics area before activating the handler. This made condition information unavailable within the handler. Now condition information is available within the handler, which can inspect it with the
GET DIAGNOSTICSstatement. The condition information is cleared when the handler exits, if it has not already been cleared during handler execution.
Previously, handlers were activated as soon as a condition occurred. Now they are not activated until the statement in which the condition occurred finishes execution, at which point the most appropriate handler is chosen. This can make a difference for statements that raise multiple conditions, if a condition raised later during statement execution has higher precedence than an earlier condition and there are handlers in the same scope for both conditions. Previously, the handler for the first condition raised would be chosen, even if it had a lower precedence than other handlers. Now the handler for the condition with the highest precedence is chosen, even if it is not the first condition raised by the statement.
Issues that caused the server to exit due to incorrect handler call stack processing were fixed.
The work just described involved several condition-handler bug fixes:
RETURNstatement did not clear the diagnostics area as it should have. Now the diagnostics area is cleared before executing
RETURN. This prevents a condition in a nested function call from incorrectly propagating to an outer scope. It also means there is no way to return an SQL warning from a stored function. This change is not backward compatible, but the resulting behavior is more like standard SQL.
When an SQL
HANDLERwas activated, the handled condition was immediately removed from the diagnostics area. Consequently, any SQL diagnostic statement executed in the handler was unable to examine the condition that activated the handler. Now condition information is available within the handler.
If multiple handlers existed at the same level within a stored program, the wrong one could be chosen. Now the handler for the highest precedence condition is chosen.
If an error occurred in a context where different handlers were present at different levels of nesting, an outer handler could be chosen rather than the innermost one.
For more information, see Scope Rules for Handlers. (Bug #12951117, Bug #38806, Bug #11749343, Bug #55852, Bug #11763171, Bug #61392, Bug #12652873, Bug #11660, Bug #11745196, Bug #48637, Bug #11756690)
Incompatible Change: MySQL now permits fractional seconds for
TIMESTAMPvalues, with up to microseconds (6 digits) precision. To define a column that includes a fractional seconds part, use the syntax
fspis the fractional seconds precision. For example:
CREATE TABLE t1 (t TIME(3), dt DATETIME(6));
fspvalue, if given, must be in the range 0 to 6. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0. (This differs from the standard SQL default of 6, for compatibility with previous MySQL versions.)
The following items summarize the implications of this change. See also Fractional Seconds in Time Values.
TIMESTAMPcolumns, the encoding and storage requirements in new tables differ from such columns in tables created previously because these types now include a fractional seconds part. This can affect the output of statements that depend on the row format, such as
Due to these changes in encoding and storage requirements for MySQL's
TIMESTAMPtypes, importing pre-MySQL 5.6.4
ALTER TABLE ... IMPORT TABLESPACEthat contain
TIMESTAMPtypes into MySQL 5.6.4 (or later) requires a workaround procedure which is described in the “Server Changes” section of Changes in MySQL 5.6 .
Syntax for temporal literals now produces temporal values:
TIME ', and
TIMESTAMP ', and the ODBC-syntax equivalents. The resulting value includes a trailing fractional seconds part if specified. Previously, the temporal type keyword was ignored and these constructs produced the string value. See Standard SQL and ODBC Date and Time Literals
Functions that take temporal arguments accept values with fractional seconds. Return values from temporal functions include fractional seconds as appropriate.
ROUTINES, now have a
DATETIME_PRECISIONcolumn. Its value is the fractional seconds precision for
NULLfor other data types.
The C API accommodates fractional seconds as follows:
MYSQL_FIELDcolumn metadata structure, the
decimalsmember indicates the fractional seconds precision for
TIMESTAMPcolumns. Clients can determine whether a result set temporal column has a fractional seconds part by checking for a nonzero
decimalsvalue in the corresponding
MYSQL_FIELDstructure. Previously, the
decimalsmember indicated the precision for numeric columns and was zero otherwise.
MYSQL_TIMEstructure used for the binary protocol, the
second_partmember indicates the microseconds part for
TIMESTAMPcolumns. Previously, the
second_partmember was unused.
In some cases, previously accepted syntax may produce different results. The following items indicate where existing code may need to be changed to avoid problems:
Some expressions produce results that differ from previous results. Examples: The
timestampsystem variable returns a value that includes a microseconds fractional part rather than an integer value. Functions that return a result that includes the current time (such as
UTC_TIMESTAMP()) interpret an argument as an
fspvalue and the return value includes a fractional seconds part of that many digits. Previously, these functions permitted an argument but ignored it.
TIMEvalues are converted to
DATETIMEby adding the time to the current date. (This means that the date part of the result differs from the current date if the time value is outside the range from
'23:59:59'.) Previously, conversion of
DATETIMEwas unreliable. See Conversion Between Date and Time Types.
TIMESTAMP(was permitted in old MySQL versions, but
Nwas a display width rather than fractional seconds precision. Support for this behavior was removed in MySQL 5.5.3, so applications that are reasonably up to date should not be subject to this issue. Otherwise, code must be rewritten.
There may be problems replicating from a master server that understands fractional seconds to an older slave that does not:
CREATE TABLEstatements containing columns that have an
fspvalue greater than 0, replication will fail due to parser errors.
Statements that use temporal data types with an
fspvalue of 0 will work for with statement-based logging but not row-based logging. In the latter case, the data types have binary formats and type codes on the master that differ from those on the slave.
Some expression results will differ on master and slave. For example, expressions that involve the
timestampsystem variable or functions that return the current time have different results, as described earlier.
(Bug #8523, Bug #11745064)
MySQL now supports
InnoDBtables. The core syntax is very similar to the
FULLTEXTcapability from earlier releases, with the
CREATE INDEXstatements, and
MATCH() AGAINST()clause in the
SELECTstatement. The new
@operator allows proximity searches for terms that are near each other in the document. The detailed search processing is controlled by a new set of configuration options:
innodb_ft_max_token_size. You can monitor the workings of the
InnoDBfull-text search system by querying new
These query optimizer improvements were implemented:
The optimizer detects and optimizes away these useless query parts within
GROUP BY, if there is no
HAVINGclause and no aggregate functions
ORDER BY, which has no effect because
LIMITis not supported in these subqueries
The Performance Schema has these additions:
The Performance Schema now permits instrument and consumer configuration at server startup, which previously was possible only at runtime using
UPDATEstatements for the
setup_consumerstables. This change was made because configuration at runtime is too late to disable instruments that have already been initialized during server startup. For example, the
wait/sync/mutex/sql/LOCK_openmutex is initialized once during server startup, so attempts to disable the corresponding instrument at runtime have no effect.
To control an instrument at server startup, use an option of this form:
instrument_nameis an instrument name such as
valueis one of these values:
0: Disable the instrument
1: Enable and time the instrument
counted: Enable and count (rather than time) the instrument
--performance-schema-instrumentoption can specify only one instrument name, but multiple instances of the option can be given to configure multiple instruments. In addition, patterns are permitted in instrument names to configure instruments that match the pattern. To configure all condition synchronization instruments as enabled and counted, use this option:
To disable all instruments, use this option:
Longer instrument name strings take precedence over shorter pattern names, regardless of order. For information about specifying patterns to select instruments, see Naming Instruments or Consumers for Filtering Operations.
An unrecognized instrument name is ignored. It is possible that a plugin installed later may create the instrument, at which time the name is recognized and configured.
To control a consumer at server startup, use an option of this form:
consumer_nameis a consumer name such as
valueis one of these values:
0: Do not collect events for the consumer
1: Collect events for the consumer
For example, to enable the
events_waits_historyconsumer, use this option:
The permitted consumer names can be found by examining the
setup_consumerstable. Patterns are not permitted.
Along with the preceding changes to permit configuration at server startup, the default instrument and consumer configuration has changed. Previously, all instruments and consumers were enabled by default. Now, instruments are disabled except the statement, I/O, and idle instruments. Consumers are disabled except the global, thread, and current-statement consumers. These changes produce a default configuration with a low overhead.
Tables that have an
EVENT_IDcolumn now also have an
END_EVENT_IDcolumn to support determination of nested event relationships:
EVENT_IDis populated with the thread current event counter when an event starts. In addition,
NULLuntil the event ends, at which point it is set to the new thread current event counter. This permits the relationship “event B is included in event A” to be determined using the following expression, without having to follow each inclusion relationship using
A.EVENT_ID <= B.EVENT_ID AND B.END_EVENT_ID <= A.END_EVENT_ID
The Performance Schema aggregates file I/O operations in two places, the
events_waits_summary_tables and the
file_summary_tables. It was possible to join the
events_waits_summary_global_by_event_nametable to the
file_summary_by_event_nameby using the
EVENT_NAMEcolumn. However, it was not possible to do the same with the
file_summary_by_instancetables because the former uses
OBJECT_INSTANCE_BEGINas the instance identifier and the latter uses
FILE_NAME. This means that it was possible to obtain both file I/O latency and usage per file, but not to correctly correlate latency to usage when there was more than one form of file (such as multiple redo logs, table files, and so forth).
To address this issue, the
file_summary_by_instancetable now has an
OBJECT_INSTANCE_BEGINcolumn. In addition, both
file_summary_by_event_namehave additional aggregation columns (such as timer wait information), which in many cases makes it possible to obtain the desired summary information without need for a join at all.
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.
Performance; InnoDB: New optimizations apply to read-only
InnoDBtransactions. See Optimizing InnoDB Read-Only Transactions for details. The new optimizations make autocommit more applicable to
InnoDBqueries than before, as a way to signal that a transaction is read-only because it is a single-statement
Performance; InnoDB: You can now set the
InnoDBpage size for uncompressed tables to 8KB or 4KB, as an alternative to the default 16KB. This setting is controlled by the
innodb_page_sizeconfiguration option. You specify the size when creating the MySQL instance. All
InnoDBtablespaces within an instance share the same page size. Smaller page sizes can help to avoid redundant or inefficient I/O for certain combinations of workload and storage devices, particularly SSD devices with small block sizes.
Replication: Previously, replication slaves could connect to the master server only through master accounts that use native authentication. Now replication slaves can also connect through master accounts that use nonnative authentication if the required client-side plugin is installed on the slave side in the directory named by the slave
plugin_dirsystem variable. (Bug #12897501)
The optimizer trace capability now tracks temporary tables created by the server during statement execution. (Bug #13400713)
Performance of metadata locking operations on Windows XP systems was improved by instituting a cache for metadata lock objects. This permits the server to avoid expensive operations for creation and destruction of synchronization objects on XP. A new system variable,
metadata_locks_cache_size, permits control over the size of the cache. The default size is 1024. (Bug #12695572)
Upgrading from an
Advanced GPLRPM package to an
AdvancedRPM package did not work. Now on Linux it is possible to use rpm -U to replace any installed MySQL product by any other of the same release family. It is not necessary to remove the old produce with rpm -e first. (Bug #11886309)
The make_win_bin_dist script is no longer used and has been removed from MySQL distributions and the manual. (Bug #58241)
Previously, MySQL servers from 5.1 and up refused to open
ARCHIVEtables created in 5.0 because opening them caused a server crash. The server now can open 5.0
REPAIR TABLEupdates them to the format used in 5.6. However, the recommended upgrade procedure is still to dump 5.0
ARCHIVEtables before upgrading and reload them after upgrading. (Bug #48633, Bug #11756687)
Error messages that referred only to an error code now also include the corresponding error description. (Bug #48348, Bug #11756433)
The MySQL code base was changed to permit use of the C++ Standard Library and to enable exceptions and runtime type information (RTTI). This change has the following implications:
Libraries and executables depend on some C++ standard library. On Linux, this has not been the case previously. On Solaris, the default dependency has changed from the default library to
libstlport, which is now included with binary distributions for users whose system does not have it.
-fno-exceptionsoptions are no longer used to build plugins, such as storage engines. Users who write their own plugins should omit these options if they were using tem.
C++ users who compile from source should set
CXXto a C++ compiler rather than a C compiler. For example, use g++ rather than gcc. This includes the server as well as client programs.
Loadable functions can be written in C++ using standard library features.
Security Enhancement; Replication: The
START SLAVEstatement now accepts
PASSWORDoptions. By default, MySQL native authentication is used, and the user name and password are stored in the
master.inforepository. This behavior can be overridden by additionally specifying the name (
DEFAULT_AUTH) and location (
PLUGIN_DIR) of an authentication plugin when issuing
START SLAVE. .
As part of this change, warnings are now issued in the following cases:
START SLAVE USER="..." PASSWORD="..."or
CHANGE MASTER TO MASTER_USER="..." MASTER_PASSWORD="..."is executed using an unencrypted connection, the warning message Sending passwords in plain text without SSL/TLS is extremely insecure is generated (
If the user name and password are stored in or read from the
master.inforepository in the course of executing
CHANGE MASTER TO, a warning message is printed out to the error log: Storing MySQL user name or password information in the master.info repository is not secure and is therefore not recommended (
The text of a running
START SLAVEstatement, including values for
PASSWORD, can be seen in the output of a concurrent
SHOW PROCESSLISTstatement. The complete text of a
CHANGE MASTER TOstatement is also visible to
See also Pluggable Authentication. (Bug #13083642)
Incompatible Change; Replication: The statements in the following list are now marked as unsafe for statement-based replication. This is due to the fact that each of these statements depends on the results of a
SELECTstatement whose order cannot always be determined. When using
STATEMENTlogging mode, a warning is issued in the binary log for any of these statements; when using
MIXEDlogging mode, the statement is logged using the row-based format.
When upgrading, you should note the use of these statements in your applications, keeping in mind that a statement that inserts or replaces rows obtained from a
SELECTcan take up many times as much space in the binary log when logged using row-based format than when only the statement itself is logged. Depending on the number and size of the rows selected and inserted (or replaced) by any such statements, the difference in size of the binary log after the logging of these statements is switched from statement-based to row-based can potentially be several orders of magnitude. See Advantages and Disadvantages of Statement-Based and Row-Based Replication. (Bug #11758262, Bug #50439)
Incompatible Change: Previously, “Aborted connection” errors were written to the error log based on the session value of
log_warnings, which permitted users with minimal privileges to cause many messages to be written to the log unless restricted by the
MAX_CONNECTIONS_PER_HOURresource limit. Now this logging is based on the global
log_warningsvariable. There are no remaining uses of the session
log_warningsvariable, so it has been removed and the variable now has only a global value. (Bug #53466, Bug #11761014)
Important Change; InnoDB: If an
ALTER TABLEstatement failed for an
InnoDBtable due to an error code from an underlying file-renaming system call,
InnoDBcould lose track of the
.ibdfile for the table. This issue only occurred when the
innodb_file_per_tableconfiguration option was enabled, and when the low-level error persisted through thousands of retry attempts. In MySQL 5.1, this issue applied to the InnoDB Plugin but not the built-in InnoDB storage engine.
For example, if you encounter an error like the following:
mysql> ALTER TABLE sb2 ADD COLUMN d2 INT; ERROR 1025 (HY000): Error on rename of './sbtest/#sql-1eb9_1' to './sbtest/sb2' (errno: -1)
you might be able to access the
#sql*table by copying an
.frmfile from a table with an identical schema. The table name to use for the
`sbtest.#mysql50##sql-1eb9_1`in the preceding example. (Bug #12884631, Bug #62146)
Important Change; Replication: Setting an empty user in a
CHANGE MASTER TOstatement caused an invalid internal result and is no longer permitted. Trying to use
MASTER_USERunset causes the statement to fail with an error. (Bug #13427949)
Performance; InnoDB: The process of deallocating the
InnoDBAdaptive Hash Index was made faster, during shutdown or when turning off the AHI with the statement:
SET GLOBAL innodb_adaptive_hash_index=OFF;
(Bug #13006367, Bug #62487)
Performance; InnoDB: This fix improves the performance of instrumentation code for
InnoDBbuffer pool operations. (Bug #12950803, Bug #62294)
Performance; InnoDB: This fix improved the efficiency and concurrency of freeing pages in the
InnoDBbuffer pool when performing a
DROP TABLEfor an
InnoDBtable when the
innodb_file_per_tableoption is enabled.
This change is most noticeable for systems with large buffer pools. During the drop operation, one traversal of the buffer pool memory structure is changed from the LRU list (the entire buffer pool) to the flush list (a much smaller structure). The LRU scanning is reduced, but not entirely eliminated. The buffer pool mutex is also released periodically, so that if the drop operation takes significant time, other threads can proceed concurrently. (Bug #11759044, Bug #51325)
InnoDB: An internal deadlock could occur within
InnoDB, on a server doing a substantial amount of change buffering for DML operations, particularly
DELETEstatements. (Bug #13340047)
InnoDB: Fixed a compilation problem that affected the
InnoDBsource code with
gcc4.6.1. The affected
InnoDBsource file was
btr/btr0cur.c. (Bug #13116045)
InnoDB: Querying the
INFORMATION_SCHEMA.INNODB_SYS_TABLESTATStable could cause the server to halt with an assertion error, in debug builds only. (Bug #12960058)
InnoDB: Unused functions were removed from the internal
InnoDBcode related to mini-transactions, to clarify the logic. (Bug #12626794, Bug #61240)
InnoDB: Lookups using secondary indexes could give incorrect matches under a specific set of conditions. The conditions involve an index defined on a column prefix, for a BLOB or other long column stored outside the index page, with a table using the Barracuda file format. (Bug #12601439, Bug #12543666)
UPDATEstatement for an
InnoDBtable could hang. The issue affects tables using the Barracuda file format and having multiple indexes on column prefixes. The size of an undo log record could exceed the page size, even though the total size of the column prefixes was less than the page size (usually 16KB). In MySQL 5.5 and higher, this error is now reported using the new code
ER_UNDO_RECORD_TOO_BIG. In MySQL 5.1 with the InnoDB Plugin, this error is reported using the existing code
ER_TOO_BIG_ROWSIZE. (Bug #12547647)
InnoDB: This fix corrects cases where the MySQL server could hang or abort with a
long semaphore waitmessage. (This is a different issue than when these symptoms occurred during a
CHECK TABLEstatement.) (Bug #11766591, Bug #59733)
INSERT...ON DUPLICATE KEYstatements for
InnoDBtables from concurrent threads could cause a deadlock, particularly with the
INSERT...ON DUPLICATE KEY UPDATEform. The problem could also be triggered by issuing multiple
INSERT IGNOREstatements. The fix avoids deadlocks caused by the same row being accessed by more than one transaction. Deadlocks could still occur when multiple rows are inserted and updated simultaneously by different transactions in inconsistent order; those types of deadlocks require the standard error handling on the application side, of re-trying the transaction. (Bug #11759688, Bug #52020, Bug #12842206)
CHECKSUM TABLEreturned 0 for a partitioned table unless the statement was used with the
EXTENDEDoption. (Bug #11933226, Bug #60681)
Partitioning: Error 1214 (
ER_TABLE_CANT_HANDLE_FT), given when trying to use a
FULLTEXTindex with a partitioned table, displayed the misleading text The used table type doesn't support FULLTEXT indexes was misleading and has been replaced with Error 1752 (
ER_FULLTEXT_NOT_SUPPORTED_WITH_PARTITIONING) which shows the more accurate FULLTEXT index is not supported for partitioned tables. (Bug #11763825, Bug #56590)
Replication: The value set for the
slave_parallel_workerssystem variable was not always honored correctly; in such cases a random value was used. (Bug #13334470)
Replication: Execution of
LOAD DATAon a
MyISAMtable having an after-insert trigger which wrote into an
InnoDBtable caused multithreaded statement-based replication to abort with error 1742 (Cannot execute the current event group in the parallel mode). (Bug #12982188)
Replication: Several warnings and informational messages were revised for typographic errors and clarity. (Bug #12947248, Bug #12978113)
Replication: When a statement containing a large number of rows to be applied on a slave table that does not contain a primary key, a considerable amount of time can be needed to find and change all the rows that are to be changed. The current fix helps diagnose this issue by printing a message to the error log if the execution time for a given statement replicated using row-based replication takes more than 60 seconds.
log_warningsmust be greater than 1 for this message to be printed to the error log. (Bug #11760927, Bug #53375)
--hexdumpprinted the last row of the hex dump incorrectly, in two ways:
If the length of the last row was eight bytes, the end of the previous row was copied to the end of the last row, padding the last row to full length.
If the length of the last row was less than sixteen bytes, its textual representation was not aligned with that of previous rows.
(Bug #11747887, Bug #34386)
Replication: A replication master could send damaged events to slaves after the binary log disk on the master became full. To correct this issue, only complete events are now pushed by the master dump thread to the slave I/O thread. In addition, the error text that the master sends to the slave when an incomplete event is found now states that the incomplete event may have been caused by running out of disk space on the master, and provides coordinates of the first and the last event bytes read. (Bug #11747416, Bug #32228)
References: See also: Bug #64035, Bug #13593869.
--replicate-rewrite-db=did not work correctly when the name of the source database (
from_name) consisted of only a single character. (Bug #34332, Bug #11747866)
InnoDBassertion could cause the server to halt. This issue only affected debug builds. The assertion referenced the source file
btr0pcur.icand the variable
cursor->pos_state. (Bug #13358468)
A derived table with more than 64 columns caused a server crash. (Bug #13354889)
InnoDBchange buffering enabled and
innodb_page_sizeset to an 8K or 4K page size, an
UPDATEstatement could fail if a column being updated contained a value longer than 1/8th of the page size. (Bug #13336585)
Writes to the slow log involved a call to
thd->current_utime()even if no log entries ended up being written, unnecessarily reducing performance. (Bug #13326965)
DBL_MAX, not 'inf'. (Bug #13261955)
For materialized temporary tables, a missing key length check could cause incorrect query results. (Bug #13261277)
Access privileges were checked for each stored program instruction, even if the instruction used no tables, resulting in reduced performance. (Bug #13251277)
The error message for
ER_EVENT_CANNOT_ALTER_IN_THE_PASTwas incorrect. (Bug #13247871)
During the table-opening process, memory was allocated and later freed that was needed view loading, even for statements that did not use views. These unnecessary allocation and free operations are no longer done. (Bug #13116518)
OUTER JOINcould return incorrect results if the subquery referred to a column from another
SELECT. (Bug #13068506)
MyISAMtemporary tables could include uninitialized data, which could contain sensitive information. Now only bytes containing initialized data are copied, which also improves performance. (Bug #12997905)
The Performance Schema nested some network I/O events within the wrong statement. (Bug #12981100)
mysql_plugin returned the wrong error code from failed server bootstrap execution. (Bug #12968567)
Internal conversion of zero to binary and back could yield a result with incorrect precision. (Bug #12911710)
Valgrind warnings generated by
filesortoperations were fixed. (Bug #12856915)
EXISTSsubquery transformation could yield incorrect results if the outer value list contained
NULL. (Bug #12838171)
With index condition pushdown enabled,
STRAIGHT_JOINqueries could produce incorrect results. (Bug #12822678, Bug #12724899)
The result of
ROUND()was incorrect for certain numbers. (Bug #12744991)
ORDER BYcould return incorrect results. (Bug #12709738)
A memory leak occurred due to failure to clean up after
QUICK_INDEX_MERGE_SELECT/Unique. (Bug #12694872, Bug #14542543)
Several improvements were made to the
libeditlibrary bundled with MySQL distributions, and that is available for all platforms that MySQL supports except Windows.
Navigation keys did not work for UTF-8 input.
Word navigation and delete operations did not work for UTF-8 input with Cyrillic characters.
Nonlatin characters were corrupted in overwrite mode for UTF-8 input.
Long queries caused the statement history file to become corrupted.
The Alt key caused history operations to fail.
(Bug #12605400, Bug #12613725, Bug #12618092, Bug #12624155, Bug #12617651, Bug #12605388)
SELECT SQL_BUFFER_RESULTquery results included too many rows if a
GROUP BYclause was optimized away. (Bug #12578908)
decimal_round()could cause a server exit when processing long numeric strings. (Bug #12563865)
As a result of the fix for this problem, it is now possible to execute statements requiring read locks on the replication log tables at any time, while any statements requiring a write lock on either or both of these tables are disallowed whenever replication is in progress. For more information, see Relay Log and Replication Metadata Repositories. (Bug #12402875, Bug #60902)
The client-server protocol now has the client send authentication data as length-encoded strings so that data longer than 256 bytes can be sent. This is done using the
CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATAclient capability. (Bug #11878962)
mysqld_safe did not properly check for an already running instance of mysqld. (Bug #11878394)
YEAR. (Bug #73543, Bug #19427648)
If index condition pushdown access was chosen and then abandoned, some variables were not cleared, leading to incorrect query results. (Bug #62533)
The CMake configuration checks did not properly test whether the C compiler supports the
inlinekeyword. (Bug #61708, Bug #12711108)
lower_case_table_namesvalue of 1 or 2 and a database having a mixed-case name, calling a stored function using a fully qualified name including the database name failed. (Bug #60347, Bug #11840395)
When a join operation contained a view, the optimizer sometimes failed to associate the view's
WHEREclause with the first table or view in a join when it was possible to do so, resulting in a less efficient query. (Bug #59696, Bug #11766559)
An assertion was raised when selecting from a view that selects from a view that used a loadable function that had been deleted. (Bug #59546, Bug #11766440)
mysql_install_db printed the
--skip-grant-tablesserver option as
--skip-grantin one of its error messages. (Bug #58534, Bug #11765553)
An assertion designed to detect zero-length sort keys also was raised when the entire key set fit in memory. (Bug #58200, Bug #11765254)
ZEROFILLvalues may be converted to string constants. However,
CASEexpressions did not handle switching data types after the planning stage, leading to
CASEfinding a null pointer instead of its argument. (Bug #57135, Bug #11764313)
If a plugin was uninstalled, thread local variables for plugin variables of string type with wth
PLUGIN_VAR_MEMALLOCflag were not freed. (Bug #56652, Bug #11763882)
Deadlock could occur when these four things happened at the same time: 1) An old dump thread was waiting for the binary log to grow. 2) The slave server that replicates from the old dump thread tried to reconnect. During reconnection, the new dump thread tried to kill the old dump thread. 3) A
KILLstatement tried to kill the old dump thread. 4) An
INSERTstatement caused a binary log rotation. (Bug #56299, Bug #11763573)
myisampack could create corrupt
FULLTEXTindexes when compressing tables. (Bug #53646, Bug #11761180)
SQL_BIG_RESULTmodifier could change the results for queries that included a
GROUP BYclause. (Bug #53534, Bug #11761078)
NULLcolumns could cause server crashes or become corrupt under concurrent load. (Bug #51252, Bug #11758979)
InnoDBused incorrect identifier quoting style in an error message that resulted in an error if a user followed the suggestion in the message. (Bug #49556, Bug #11757503)
Concurrent access to
ARCHIVEtables could cause corruption. (Bug #42784, Bug #11751793)
A query that selected a
GROUP_CONCAT()function result could return different values depending on whether an
ORDER BYof the function result was present. (Bug #41090, Bug #11750518)
A linking problem prevented the
FEDERATEDstorage engine plugin from loading. (Bug #40942, Bug #11750417)
Subqueries could return incorrect results when materialization was enabled. (Bug #40037, Bug #11749901, Bug #12705660, Bug #12908058)
For debug builds, an assertion could be raised for
ALTERstatements that performed a
RENAMEoperation. This occurred for storage engine handlertons that exposed the
HTON_FLUSH_AFTER_RENAMEflag. (Bug #38028, Bug #11749050)
The estimate of space required for
filesortoperations could be too high, resulting in inefficient initialization. (Bug #37359, Bug #11748783)
ALTER TABLEthat included an
ADD ... AFTERoperation to add a new column after a column that had been modified earlier in the statement failed to find the existing column. (Bug #34972, Bug #11748057)
FEDERATEDtables, loss of connection to the remote table during some insert operations could cause a server crash. (Bug #34660, Bug #11747970)
Collation for the
SPACE()function was determined by the parse time value of the
collation_connectionsystem variable (instead of the runtime value), which could give unexpected results from prepared statements, triggers, and stored procedures. (Bug #23637, Bug #11746123)