MySQL 歷史版本列表 Page42

更新時間：2013-08-02
更新細節：

What's new in this version:

Functionality Added or Changed:
- comp_err now checks to make sure that new errors are not being added to MySQL 5.1 or 5.5 because the set of errors for these series is frozen. 

Bugs Fixed
- InnoDB: During an insert buffer merge, InnoDB would invoke lock_rec_restore_from_page_infimum() on a potentially invalid record pointer. 
- InnoDB: The page_zip_validate() consistency check would fail after compressing a page, in page_zip_compress(). This problem was caused by page_zip_decompress(), which would fail to set heap_no correctly when a record contained no user data bytes. A record with no user data bytes occurs when, for example, a primary key is an empty string and all secondary index fields are NULL or an empty string. 
- InnoDB: The pthread_mutex, commit_threads_m, which was initialized but never used, has been removed from the code base. 
- Partitioning: When dropping a partitioned table, the table's .par file was deleted first, before the table definition or data. This meant that, if the server failed during the drop operation, the table could be left in an inconsistent state in which it could neither be accessed nor dropped.
- Shared-compatibility conflict errors occurred for RPM install operations, even if no shared-compatibility RPMs were already installed. 
- A user variable referenced during execution of a prepared statement is set to memory that is freed at the end of execution. A second execution of the statement could result in Valgrind warnings when accessing this memory. 
- Misoptimization of left expressions in prepared statements could cause a server exit. 
- Subsequent to Prepared statement needs to be re-prepared errors, inserts into DECIMAL columns caused a server exit. 
- Assigning the result of a subquery to a user variable raised an assertion when the outer query included DISTINCT and GROUP BY.

更新時間：2013-08-01
更新細節：

What's new in this version:

Functionality Added or Changed:
- Important Change; Replication: By default, when promoting integers from a smaller type on the master to a larger type on the slave (for example, from a SMALLINT column on the master to a BIGINT column on the slave), the promoted values are treated as though they are signed. Now in such cases it is possible to modify or override this behavior using one or both of ALL_SIGNED, ALL_UNSIGNED in the set of values specified for the slave_type_conversions server system variable. For more information, see Row-based replication: attribute promotion and demotion, as well as the description of the variable. (Bug #15831300)
- Previously, program options could be specified in full or as any unambiguous prefix. For example, the --compress option could be given to mysqldump as --compr, but not as --comp because the latter is ambiguous. Option prefixes now are deprecated. They can cause problems when new options are implemented for programs. A prefix that is currently unambiguous might become ambiguous in the future. If an unambiguous prefix is given, a warning now occurs to provide feedback. Warning: Using unique option prefix compr instead of compress is deprecated and will be removed in a future release. Please use the full name instead.
- Option prefixes are no longer supported in MySQL 5.7; only full options are accepted. (Bug #16996656)
- The C API libmysqlclient shared-library .so files now have version 18.1.0 (up from version 18.0.0 used in MySQL 5.5). (Bug #16809055)
- In batch mode, mysql formatted result status messages such as “"Query OK, 1 row affected"” but did not print them. Now these messages are not formatted. (Bug #69486, Bug #16971432)

Bugs Fixed:
- Performance; Important Change; InnoDB: InnoDB would fail to open a tablespace that has multiple data files. This removes the known limitation that was in MySQL Server 5.6.12. (Bug #17033706, Bug #69623)
- Performance; InnoDB: A code regression introduced in MySQL 5.6 negatively impacted DROP TABLE and ALTER TABLE performance. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x. (Bug #16864741, Bug #69316)
- Performance; InnoDB: When innodb_thread_concurrency is set to a non-zero value, there was a possibility that all innodb_concurrency_tickets would be released after each row was read, resulting in a concurrency check after each read. This could impact performance of all queries. One symptom could be higher system CPU usage. We strongly recommend that you upgrade to MySQL Server 5.6.13 if you use this setting. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x. (Bug #68869, Bug #16622478)
- Incompatible Change: It is possible for a column DEFAULT value to be valid for the sql_mode value at table-creation time but invalid for the sql_mode value when rows are inserted or updated. In this case, 0 should be accepted for the CREATE TABLE but rejected for the INSERT. However, the server did not evaluate DEFAULT values used for inserts or updates against the current sql_mode. In the example, the INSERT succeeds and inserts '0000-00-00' into the DATE column.
- The server now applies the proper sql_mode checks to generate a warning or error at insert or update time.
- A resulting incompatibility for replication if you use statement-based logging (binlog_format=STATEMENT) is that if a slave is upgraded, a nonupgraded master will execute the preceding example without error, whereas the INSERT will fail on the slave and replication will stop.
- To deal with this, stop all new statements on the master and wait until the slaves catch up. Then upgrade the slaves followed by the master. Alternatively, if you cannot stop new statements, temporarily change to row-based logging on the master (binlog_format=ROW) and wait until all slaves have processed all binary logs produced up to the point of this change. Then upgrade the slaves followed by the master and change the master back to statement-based logging. (Bug #68041, Bug #16078943)
- MySQL Cluster: CREATE LOGFILE GROUP failed with a syntax error when INITIAL_SIZE, UNDO_BUFFER_SIZE, or both options were specified. (Bug #13116514)
- InnoDB: The server would crash during a memcached set operation. The failure was due to a padded length value for a utf8 char column. During a memcached update operation, a field from an old tuple would be copied with a data length that was less than the padded utf8 char column value. This fix ensures that old tuples are not copied. Instead, a new tuple is created each time. (Bug #16875543)
- InnoDB: When CHECK TABLE found a secondary index that contained the wrong number of entries, it would report an error but not mark the index as corrupt. CHECK TABLE now marks the index as corrupt when this error is encountered, but only the index is marked as corrupt, not the table. As a result, only the index becomes unusable until it is dropped and rebuilt. The table is unaffected. (Bug #16914007)
- InnoDB: InnoDB would attempt to gather statistics on partially created indexes. (Bug #16907783)
- InnoDB: A full-text search using the IN BOOLEAN MODE modifier would result in an assertion failure. (Bug #16927092)
- References: This bug is a regression of Bug #16516193.
- InnoDB: The two INFORMATION_SCHEMA tables for the InnoDB buffer pool could show an invalid page type for read-fixed blocks. This fix will show the unknown page type for blocks that are I/O-fixed for reading. (Bug #16859867)
- InnoDB: During an insert buffer merge, InnoDB would invoke lock_rec_restore_from_page_infimum() on a potentially invalid record pointer. (Bug #16806366)
- InnoDB: The innodb_rwlock_x_spin_waits item in the INFORMATION_SCHEMA.INNODB_METRICS table would show the same value as the innodb_rwlock_x_os_waits item. (Bug #16798175)
- InnoDB: A memory leak would occur when inserting or replacing a row in a full-text search index on a table with more than 96 columns. (Bug #16809167)
- InnoDB: In debug builds, an assertion could occur in OPT_CHECK_ORDER_BY when using binary directly in a search string, as binary may include NULL bytes and other non-meaningful characters. This fix will remove non-meaningful characters before the search is run. (Bug #16766016)
- InnoDB: The page_zip_validate() consistency check would fail after compressing a page, in page_zip_compress(). This problem was caused by page_zip_decompress(), which would fail to set heap_no correctly when a record contained no user data bytes. A record with no user data bytes occurs when, for example, a primary key is an empty string and all secondary index fields are NULL or an empty string. (Bug #16736929)
- InnoDB: A race condition would occur between ALTER TABLE ... ADD KEY and INSERT statements, resulting in an “Unable to Purge a Record” error. (Bug #16628233)
- InnoDB: A full-text search that returns large result sets would consume an excessive amount of memory due to use of a red-black tree for holding full-text search results. This fix reduces and imposes a limit on memory consumption. If the limit is exceeded, a message is returned indicating that the full-text search query exceeds the maximum allowed memory. (Bug #16625973)
- InnoDB: Restarting InnoDB in read-only mode and running a workload would occasionally return a global_segment < os_aio_n_segments assertion. (Bug #16362046)
- InnoDB: When the InnoDB shutdown mode (innodb_fast_shutdown) is set to 2 and the master thread enters the flush loop, the thread would not be able to exit under some circumstances. This could lead to a shutdown hang. (Bug #16411457)
- InnoDB: While printing a UTF-8 table name, InnoDB would truncate the table name, resulting in an incomplete buffer and subsequent Valgrind error. This bug fix also addresses an incorrect debugging error message. (Bug #16066351)
- InnoDB: Attempting to create a table while in innodb_read_only mode would result in the following error: ERROR 1015 (HY000): Can't lock file (errno: 165 - Table is read only). (Bug #15963619)
- InnoDB: Due to a resource related bug, creating numerous tables that have a simple a full-text search index would cause excessive memory usage. This fix adds a global configuration parameter to limit the total memory size that full-text search indexes can use. If the global memory limit is reached by an index operation, a force sync is triggered. (Bug #14834698, Bug #16817453)
- InnoDB: In the error log, a full-text search index would be reported missing from the data dictionary during a TRUNCATE TABLE operation. After restarting mysqld, the following InnoDB error would be reported: “InnoDB: Error: trying to load index idx13 for table test/g1 but the index tree has been freed..” (Bug #12429565)
- InnoDB: Creating a table with a comment or default textual value containing an apostrophe that is escaped with a backslash would sometimes cause the InnoDB storage engine to omit foreign key definitions. (Bug #61656, Bug #12762377)
- InnoDB: Setting foreign_key_checks=0 and running ALTER TABLE to change the character set of foreign key columns for a database with multiple tables with foreign key constraints would leave the database in an inconsistent state. Subsequent ALTER TABLE operations (using the COPY algorithm) with foreign_key_checks=1 would fail due to the detected inconsistency. Reversion of the partially executed ALTER TABLE operation would also fail, resulting in the loss of the table being altered. When running the same ALTER TABLE operation with a RENAME clause, the inconsistency would not be detected but if the ALTER TABLE operation failed for some other reason, reversion of the partially executed ALTER TABLE would fail with the same result.
- The bug fix temporarily disables foreign_key_checks while the previous table definition is restored. (Bug #65701, Bug #14227431)
- InnoDB: Successive deletes in descending key order would lead to under-filled InnoDB index pages. When an InnoDB index page is under-filled, it is merged with the left or right sibling node. The check performed to determine if a sibling node is available for merging was not functioning correctly. (Bug #68501, Bug #16417635)
- InnoDB: The pthread_mutex, commit_threads_m, which was initialized but never used, has been removed from the code base. (Bug #60225, Bug #11829813)
- InnoDB: When running an InnoDB full-text search in boolean mode, prefixing an asterisk (*) to a search string ('*string') would result in an error whereas for MyISAM, a prefixed asterisk would be ignored. To ensure compatibility between InnoDB and MyISAM, InnoDB now handles a prefixed asterisk in the same way as MyISAM. (Bug #68948, Bug #16660607)
- InnoDB: The row_check_index_for_mysql method, which checks for NULL fields during an index scan or CHECK TABLE operation, would iterate unnecessarily. Thanks to Po-Chun Chang for the patch to correct this issue. (Bug #69377, Bug #16896647)
- Partitioning: When upgrading to MySQL 5.5.31 or higher, a message is written into the output of mysql_upgrade when encountering a partitioned table for which the ALGORITHM option is required to maintain binary compatibility with the original; the message includes the ALTER TABLE statement required to make the change. For such a table having a sufficiently large number of partitions, the message was truncated with an error before the complete ALTER TABLE statement could be written. (Bug #16589511)
- Partitioning: When a range specified in the WHERE condition of a query against a table partitioned by RANGE entirely within that of one of the partitions, the next partition was also checked for rows although it should have been pruned away. In this case, partition pmax was checked, even though the range given in the WHERE clause lay entirely within partition p3. (Bug #16447483)
- Partitioning: When dropping a partitioned table, the table's .par file was deleted first, before the table definition or data. This meant that, if the server failed during the drop operation, the table could be left in an inconsistent state in which it could neither be accessed nor dropped.
- Now, when dropping a partitioned table, the table's .par file is not removed until all table data has been deleted.
- When executing DROP TABLE of a partitioned table, in the event that its .par file is determined to be missing, the table's .frm file is now immediately deleted, in effect forcing the drop to complete.
- Replication: The condition leading to the issue fixed in Bug #16579083 continued to raise an error even though the condition itself no longer cause the issue to occur. (Bug #16931177, Bug #69369)
- References: See also Bug #16271657, Bug #16491597, Bug #68251, Bug #68569.
- Replication: When rpl_semi_sync_master_timeout was set to an extremely large value, semi-synchronous replication became very slow, especially when many sessions were working in parallel. It was discovered that the code to calculate this timeout was inside the wait loop itself, with the result that an increase in the value of rpl_semi_sync_master_timeout caused repeated iterations. This fix improves the method used to calculate wakeup times, and moves it outside of the wait loop, so that it is executed one time only. (Bug #16878043, Bug #69341)
- Replication: It was possible to cause a deadlock after issuing FLUSH TABLES WITH READ LOCK by issuing STOP SLAVE in a new connection to the slave, then issuing SHOW SLAVE STATUS using the original connection.
- The fix for this includes the addition of the rpl_stop_slave_timeout system variable, to control the time in seconds to wait for slave to stop after issuing STOP SLAVE before returning a warning. (Bug #16856735)
- Replication: Some expressions employing variables were not handled correctly by LOAD DATA. (Bug #16753869)
- Replication: In some circumstances, the message in the Last_Error column from the output of SHOW SLAVE STATUS referred to GTID_NEXT_LIST although this variable is not currently implemented (the name is reserved for possible future use). Now in such cases the error message no longer refers to this variable. (Bug #16742886, Bug #69096)
- References: See also Bug #16715809, Bug #69045.
- Replication: The error displayed by SHOW SLAVE STATUS when a worker thread fails to apply an event contained no event coordinate information. The GTID for the event's group was also not shown. Now in such cases, the text shown for Last_SQL_Error is prefixed with the (physical) master binary log coordinates, as well as the value of gtid_next when this has been set. (Bug #16594095)
- Replication: Linker errors occurred if the header file log_event.h was included in an application containing multiple source files, because the file rpl_tblmap.cc was included in log_event.h. This fix moves the inclusion of rpl_tblmap.cc into the source files that use log_event.h. (Bug #16607258)
- Replication: The warning issued when specifying MASTER_USER or MASTER_PASSWORD with CHANGE MASTER TO was unclear for a number of reasons, and has been changed to read, Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see 'START SLAVE Syntax' in the MySQL Manual for more information. (Bug #16460123, Bug #16461303, Bug #68602, Bug #68599)
- Replication: After a transaction was skipped due to its GTID already having been logged, all remaining executed transactions were incorrectly skipped until gtid_next was pointed to a different GTID.
- To avoid this incorrect behavior, all transactions—even those that have been skipped—are marked as undefined when they are commited or rolled back, so that an error is thrown whenever a second transaction is executed following the same SET @@session.gtid_next statement. (Bug #16223835)
- Replication: After the client thread on a slave performed a FLUSH TABLES WITH READ LOCK and was followed by some updates on the master, the slave hung when executing SHOW SLAVE STATUS. (Bug #68460, Bug #16387720)
- For debug builds, improper use of SAFE_MUTEX within dbug.c caused different code areas to have different ideas about size and contents of a mutex. This could result in out-of-bounds memory writes. (Bug #16945343)
- Sql_condition::set_subclass_origin() could perform an out-of-bounds read. (Bug #16969091)
- Initialization of keycache_* variables (see Multiple Key Caches) during server startup could write to incorrect memory. (Bug #16945503)
- Reads from message buffers for closed connections could occur. (Bug #17003702)
- The server could exit while using a cursor to fetch rows from a UNION query. (Bug #16983143)
- The range optimizer incorrectly assumed that any geometry function on a spatial index returned rows in ROWID order, which could result in incorrect query results. (Bug #16960800)
- The server did excessive locking on the LOCK_active_mi and active_mi->rli->data_lock mutexes for any SHOW STATUS LIKE 'pattern' statement, even when the pattern did not match status variables that use those mutexes (Slave_heartbeat_period, Slave_last_heartbeat, Slave_received_heartbeats, Slave_retried_transactions, Slave_running). Now attempts to show those variables do not lock those mutexes. This might result is slightly stale data, but better performance. (Bug #16904035)
- Full-text phrase search in InnoDB tables could read incorrect memory. (Bug #16885178)
- It was not possible to keep several major versions of MySQL in the same yum repository. (Bug #16878042)
- The Performance Schema could spawn a thread using incorrect instrumentation information. (Bug #16939689)
- INSERT ... ON DUPLICATE KEY UPDATE could cause a server exit if a column with no default value was set to DEFAULT. (Bug #16756402)
- References: This bug is a regression of Bug #14789787.
- The code base was modified to account for new warning checks introduced by gcc 4.8. (Bug #16729109)
- Compiling failed with -DMY_ATOMIC_MODE_RWLOCKS=1 or on platforms on which MySQL did not support lockless atomic operations (such as ARM). (Bug #16736461)
- In a prepared statement or stored routine, if the HAVING clause of a subquery referenced some column of the GROUP BY of the parent query, the server could exit. (Bug #16739050)
- The read-only open_files_limit system variable did not show maximum number of open files the mysqld process could have, but instead the number that was requested after adjusting the --open-files-limit command-line option. (Bug #16657588)
- Some rows for a session could be missing sporadically from the Performance Schema session_connect_attrs table while the session was executing a workload. (Bug #16576980)
- The server could make the wrong decision about whether an account password was expired. (Bug #16604641)
- Upgrading from community SLES RPM packages to commercial packages for the same MySQL version failed with conflict errors. (Bug #16545296)
- A full-text search syntax error failed to print to standard output. (Bug #16429688, Bug #16765397)
- Unlike MyISAM, InnoDB does not support boolean full-text searches on nonindexed columns, but this restriction was not enforced, resulting in queries that returned incorrect results. (Bug #16434374)
- If the optimizer was using a loose index scan, the server could exit while attempting to create a temporary table. (Bug #16436567)
- Incorrect results or a server exit could be caused by a reference to an aggregated expression inside a nested subquery, where the aggregated expression was evaluated in a query block more than two levels outer to the reference. (Bug #16436383)
- In debug builds, failure in the range optimizer for an ER_LOCK_DEADLOCK or ER_LOCK_WAIT_TIMEOUT error could go undetected and cause an assertion to be raised when a response was sent to the client. In release builds, this problem manifested as clients receiving an OK for a statement that had failed. (Bug #16366994, Bug #16247110)
- An assertion could be raised when creating a index on a prefix of a TINYBLOB column in an InnoDB column. (Bug #16368875)
- A server exit could occur for queries of the form SELECT (SELECT 1 FROM t1) IN (SELECT a FROM t1) when attempting to evaluate the constant left-hand argument to the IN subquery predicate. (Bug #16369522)
- No warning was generated if a duplicate index existed after dropping a column associated with a multiple-column index. (Bug #16315351)
- SELECT DISTINCT with WITH ROLLUP could result in a Duplicate entry 'NULL' for key '' error. (Bug #16314835)
- The server could exit in do_copy_not_null() due to an improper NULL-value check. (Bug #16316564)
- Transforming some subqueries that select temporal or BIGINT types or to a semijoin caused a server exit on the second execution of prepared statements or stored programs. (Bug #16319671)
- The usual failed-login attempt accounting was not applied to failed COM_CHANGE_USER commands. (Bug #16241992)
- A user variable referenced during execution of a prepared statement is set to memory that is freed at the end of execution. A second execution of the statement could result in Valgrind warnings when accessing this memory. (Bug #16119355)
- Misoptimization of left expressions in prepared statements could cause a server exit. (Bug #16095534)
- The optimizer trace could print ranges for key parts that were not usable for range access. (Bug #14615536)
- When running a query on INFORMATION_SCHEMA.INNODB_BUFFER_PAGE that requested table_name and index_name values, query results would include index pages without table_name or index_name values. (Bug #14529666)
- Several COM_xxx commands in the client-server protocol did not have length checks for incoming network packets, which could result in various problems for malformed input. (Bug #14525642)
- Passwords in statements were not obfuscated before being written to the audit log. (Bug #14536456)
- With the thread pool plugin in use, normal connection termination caused the Aborted_clients status variable to be incremented. (Bug #14081240)
- On Windows, command-line options of the form --opt_name="opt_value" worked but --opt_name='opt_value' did not.
- On all platforms, for Performance Schema options of the form --performance_schema_instrument="instrument=value", invalid instrument names now are rejected. (Bug #13955232)
- MySQL Installer, if run in custom install or change mode, offered installation options that had no effect. (Bug #12928601)
- Incorrect results could be returned from queries that used several aggr_func(DISTINCT) functions (where aggr_func() is an aggregate function such as COUNT()) when these referred to different columns of the same composite key. (Bug #12328597)
- If an UPDATE containing a subquery caused a deadlock inside InnoDB, the deadlock was not properly handled by the SQL layer. The SQL layer then tried to unlock the row after InnoDB rolled back the transaction, raising an assertion inside InnoDB. (Bug #69127, Bug #16757869)
- Boolean plugin system variables did not behave well on machines where char is unsigned; some code attempted to assign a negative value to these. (Bug #59905, Bug #11864205)
- In the absence of SQL_CALC_FOUND_ROWS in the preceding query, FOUND_ROWS() should return the number of rows in the result set, but this did not always happen if the query contained ORDER BY. (Bug #69271, Bug #16827872)
- Unoptimized versions of the xxxkorr() macros in my_global.h were used on 64-bit x86 processors. (Bug #61179, Bug #12565703)
- sql-common/client_plugin.c contained a nonportable use of a va_list parameter. (Bug #62769, Bug #13252623)
- mysqldump assumed the existence of the general_log and slow_log tables in the mysql database. It failed if invoked to dump tables from an older server where these tables do not exist. (Bug #65670, Bug #14236170)
- Full-text search on InnoDB tables failed on searches for words containing apostrophes. (Bug #69216, Bug #16801781)
- Full-text search on InnoDB tables failed on searches for literal phrases combined with + or - operators. (Bug #68720, Bug #16516193)
- Optimizations that used extended secondary keys (see Use of Index Extensions) worked only for InnoDB, even for storage engines with the requisite underlying capabilities. (Bug #68469, Bug #16391678)
- With big_tables enabled, queries that used COUNT(DISTINCT) on a simple join with a constant equality condition on a non-duplicate key returned incorrect results. (Bug #52582, Bug #11760197)
- mysql_install_db incorrectly tried to create the mysql.innodb_table_stats and mysql.innodb_index_stats tables if InnoDB was not available. (Bug #68438, Bug #16369955)
- If one session had any metadata lock on a table, another session attempting CREATE TABLE [IF NOT EXISTS] for the same table would hang. This occurred due to an attempt in the second session to acquire an exclusive metadata lock on the table before checking whether the table already existed. An exclusive metadata lock is not compatible with any other metadata locks, so the session hung for the lock timeout period if another session had the table locked.
- Now the server attempts to acquire a shared metadata lock on the table first to check whether it exists, then upgrade to an exclusive lock if it does not. If the table does exist, an error occurs for CREATE TABLE and a warning for CREATE TABLE IF NOT EXISTS. (Bug #63144, Bug #13418638)
- Attempts to build from a source RPM package could fail because the build process attempted to refer to a pb2user that might not exist. (Bug #64641, Bug #13865797, Bug #69339, Bug #16874980)
- A typo in cmake/dtrace.cmake prevented DTrace support from being enabled by -DENABLE_DTRACE-on. (Bug #60743, Bug #12325449)
- When an internal buffer was too small for the workload, the Performance Schema could spend a lot of time in an internal spin loop attempting to allocate a memory buffer, and fail. (Bug #69382, Bug #16945618)
- Some LEFT JOIN queries with GROUP BY could return incorrect results. (Bug #68897, Bug #16620047)
- References: This bug is a regression of Bug #11760517.
- For queries with ORDER BY ... LIMIT, the optimizer could choose a nonordering index for table access. (Bug #69410, Bug #16916596)
- When selecting a union of an empty result set (created with WHERE 1=0 or WHERE FALSE) with a derived table, incorrect filtering was applied to the derived table. (Bug #69471, Bug #16961803)
- References: This bug is a regression of Bug #15848521.
- Comparison of a DATETIME value and a string did not work correctly for the utf8_unicode_ci collation. (Bug #68795, Bug #16567381)

更新時間：2013-08-01
更新細節：

What's new in this version:

Functionality Added or Changed:
- Important Change; Replication: By default, when promoting integers from a smaller type on the master to a larger type on the slave (for example, from a SMALLINT column on the master to a BIGINT column on the slave), the promoted values are treated as though they are signed. Now in such cases it is possible to modify or override this behavior using one or both of ALL_SIGNED, ALL_UNSIGNED in the set of values specified for the slave_type_conversions server system variable. For more information, see Row-based replication: attribute promotion and demotion, as well as the description of the variable. (Bug #15831300)
- Previously, program options could be specified in full or as any unambiguous prefix. For example, the --compress option could be given to mysqldump as --compr, but not as --comp because the latter is ambiguous. Option prefixes now are deprecated. They can cause problems when new options are implemented for programs. A prefix that is currently unambiguous might become ambiguous in the future. If an unambiguous prefix is given, a warning now occurs to provide feedback. Warning: Using unique option prefix compr instead of compress is deprecated and will be removed in a future release. Please use the full name instead.
- Option prefixes are no longer supported in MySQL 5.7; only full options are accepted. (Bug #16996656)
- The C API libmysqlclient shared-library .so files now have version 18.1.0 (up from version 18.0.0 used in MySQL 5.5). (Bug #16809055)
- In batch mode, mysql formatted result status messages such as “"Query OK, 1 row affected"” but did not print them. Now these messages are not formatted. (Bug #69486, Bug #16971432)

Bugs Fixed:
- Performance; Important Change; InnoDB: InnoDB would fail to open a tablespace that has multiple data files. This removes the known limitation that was in MySQL Server 5.6.12. (Bug #17033706, Bug #69623)
- Performance; InnoDB: A code regression introduced in MySQL 5.6 negatively impacted DROP TABLE and ALTER TABLE performance. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x. (Bug #16864741, Bug #69316)
- Performance; InnoDB: When innodb_thread_concurrency is set to a non-zero value, there was a possibility that all innodb_concurrency_tickets would be released after each row was read, resulting in a concurrency check after each read. This could impact performance of all queries. One symptom could be higher system CPU usage. We strongly recommend that you upgrade to MySQL Server 5.6.13 if you use this setting. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x. (Bug #68869, Bug #16622478)
- Incompatible Change: It is possible for a column DEFAULT value to be valid for the sql_mode value at table-creation time but invalid for the sql_mode value when rows are inserted or updated. In this case, 0 should be accepted for the CREATE TABLE but rejected for the INSERT. However, the server did not evaluate DEFAULT values used for inserts or updates against the current sql_mode. In the example, the INSERT succeeds and inserts '0000-00-00' into the DATE column.
- The server now applies the proper sql_mode checks to generate a warning or error at insert or update time.
- A resulting incompatibility for replication if you use statement-based logging (binlog_format=STATEMENT) is that if a slave is upgraded, a nonupgraded master will execute the preceding example without error, whereas the INSERT will fail on the slave and replication will stop.
- To deal with this, stop all new statements on the master and wait until the slaves catch up. Then upgrade the slaves followed by the master. Alternatively, if you cannot stop new statements, temporarily change to row-based logging on the master (binlog_format=ROW) and wait until all slaves have processed all binary logs produced up to the point of this change. Then upgrade the slaves followed by the master and change the master back to statement-based logging. (Bug #68041, Bug #16078943)
- MySQL Cluster: CREATE LOGFILE GROUP failed with a syntax error when INITIAL_SIZE, UNDO_BUFFER_SIZE, or both options were specified. (Bug #13116514)
- InnoDB: The server would crash during a memcached set operation. The failure was due to a padded length value for a utf8 char column. During a memcached update operation, a field from an old tuple would be copied with a data length that was less than the padded utf8 char column value. This fix ensures that old tuples are not copied. Instead, a new tuple is created each time. (Bug #16875543)
- InnoDB: When CHECK TABLE found a secondary index that contained the wrong number of entries, it would report an error but not mark the index as corrupt. CHECK TABLE now marks the index as corrupt when this error is encountered, but only the index is marked as corrupt, not the table. As a result, only the index becomes unusable until it is dropped and rebuilt. The table is unaffected. (Bug #16914007)
- InnoDB: InnoDB would attempt to gather statistics on partially created indexes. (Bug #16907783)
- InnoDB: A full-text search using the IN BOOLEAN MODE modifier would result in an assertion failure. (Bug #16927092)
- References: This bug is a regression of Bug #16516193.
- InnoDB: The two INFORMATION_SCHEMA tables for the InnoDB buffer pool could show an invalid page type for read-fixed blocks. This fix will show the unknown page type for blocks that are I/O-fixed for reading. (Bug #16859867)
- InnoDB: During an insert buffer merge, InnoDB would invoke lock_rec_restore_from_page_infimum() on a potentially invalid record pointer. (Bug #16806366)
- InnoDB: The innodb_rwlock_x_spin_waits item in the INFORMATION_SCHEMA.INNODB_METRICS table would show the same value as the innodb_rwlock_x_os_waits item. (Bug #16798175)
- InnoDB: A memory leak would occur when inserting or replacing a row in a full-text search index on a table with more than 96 columns. (Bug #16809167)
- InnoDB: In debug builds, an assertion could occur in OPT_CHECK_ORDER_BY when using binary directly in a search string, as binary may include NULL bytes and other non-meaningful characters. This fix will remove non-meaningful characters before the search is run. (Bug #16766016)
- InnoDB: The page_zip_validate() consistency check would fail after compressing a page, in page_zip_compress(). This problem was caused by page_zip_decompress(), which would fail to set heap_no correctly when a record contained no user data bytes. A record with no user data bytes occurs when, for example, a primary key is an empty string and all secondary index fields are NULL or an empty string. (Bug #16736929)
- InnoDB: A race condition would occur between ALTER TABLE ... ADD KEY and INSERT statements, resulting in an “Unable to Purge a Record” error. (Bug #16628233)
- InnoDB: A full-text search that returns large result sets would consume an excessive amount of memory due to use of a red-black tree for holding full-text search results. This fix reduces and imposes a limit on memory consumption. If the limit is exceeded, a message is returned indicating that the full-text search query exceeds the maximum allowed memory. (Bug #16625973)
- InnoDB: Restarting InnoDB in read-only mode and running a workload would occasionally return a global_segment < os_aio_n_segments assertion. (Bug #16362046)
- InnoDB: When the InnoDB shutdown mode (innodb_fast_shutdown) is set to 2 and the master thread enters the flush loop, the thread would not be able to exit under some circumstances. This could lead to a shutdown hang. (Bug #16411457)
- InnoDB: While printing a UTF-8 table name, InnoDB would truncate the table name, resulting in an incomplete buffer and subsequent Valgrind error. This bug fix also addresses an incorrect debugging error message. (Bug #16066351)
- InnoDB: Attempting to create a table while in innodb_read_only mode would result in the following error: ERROR 1015 (HY000): Can't lock file (errno: 165 - Table is read only). (Bug #15963619)
- InnoDB: Due to a resource related bug, creating numerous tables that have a simple a full-text search index would cause excessive memory usage. This fix adds a global configuration parameter to limit the total memory size that full-text search indexes can use. If the global memory limit is reached by an index operation, a force sync is triggered. (Bug #14834698, Bug #16817453)
- InnoDB: In the error log, a full-text search index would be reported missing from the data dictionary during a TRUNCATE TABLE operation. After restarting mysqld, the following InnoDB error would be reported: “InnoDB: Error: trying to load index idx13 for table test/g1 but the index tree has been freed..” (Bug #12429565)
- InnoDB: Creating a table with a comment or default textual value containing an apostrophe that is escaped with a backslash would sometimes cause the InnoDB storage engine to omit foreign key definitions. (Bug #61656, Bug #12762377)
- InnoDB: Setting foreign_key_checks=0 and running ALTER TABLE to change the character set of foreign key columns for a database with multiple tables with foreign key constraints would leave the database in an inconsistent state. Subsequent ALTER TABLE operations (using the COPY algorithm) with foreign_key_checks=1 would fail due to the detected inconsistency. Reversion of the partially executed ALTER TABLE operation would also fail, resulting in the loss of the table being altered. When running the same ALTER TABLE operation with a RENAME clause, the inconsistency would not be detected but if the ALTER TABLE operation failed for some other reason, reversion of the partially executed ALTER TABLE would fail with the same result.
- The bug fix temporarily disables foreign_key_checks while the previous table definition is restored. (Bug #65701, Bug #14227431)
- InnoDB: Successive deletes in descending key order would lead to under-filled InnoDB index pages. When an InnoDB index page is under-filled, it is merged with the left or right sibling node. The check performed to determine if a sibling node is available for merging was not functioning correctly. (Bug #68501, Bug #16417635)
- InnoDB: The pthread_mutex, commit_threads_m, which was initialized but never used, has been removed from the code base. (Bug #60225, Bug #11829813)
- InnoDB: When running an InnoDB full-text search in boolean mode, prefixing an asterisk (*) to a search string ('*string') would result in an error whereas for MyISAM, a prefixed asterisk would be ignored. To ensure compatibility between InnoDB and MyISAM, InnoDB now handles a prefixed asterisk in the same way as MyISAM. (Bug #68948, Bug #16660607)
- InnoDB: The row_check_index_for_mysql method, which checks for NULL fields during an index scan or CHECK TABLE operation, would iterate unnecessarily. Thanks to Po-Chun Chang for the patch to correct this issue. (Bug #69377, Bug #16896647)
- Partitioning: When upgrading to MySQL 5.5.31 or higher, a message is written into the output of mysql_upgrade when encountering a partitioned table for which the ALGORITHM option is required to maintain binary compatibility with the original; the message includes the ALTER TABLE statement required to make the change. For such a table having a sufficiently large number of partitions, the message was truncated with an error before the complete ALTER TABLE statement could be written. (Bug #16589511)
- Partitioning: When a range specified in the WHERE condition of a query against a table partitioned by RANGE entirely within that of one of the partitions, the next partition was also checked for rows although it should have been pruned away. In this case, partition pmax was checked, even though the range given in the WHERE clause lay entirely within partition p3. (Bug #16447483)
- Partitioning: When dropping a partitioned table, the table's .par file was deleted first, before the table definition or data. This meant that, if the server failed during the drop operation, the table could be left in an inconsistent state in which it could neither be accessed nor dropped.
- Now, when dropping a partitioned table, the table's .par file is not removed until all table data has been deleted.
- When executing DROP TABLE of a partitioned table, in the event that its .par file is determined to be missing, the table's .frm file is now immediately deleted, in effect forcing the drop to complete.
- Replication: The condition leading to the issue fixed in Bug #16579083 continued to raise an error even though the condition itself no longer cause the issue to occur. (Bug #16931177, Bug #69369)
- References: See also Bug #16271657, Bug #16491597, Bug #68251, Bug #68569.
- Replication: When rpl_semi_sync_master_timeout was set to an extremely large value, semi-synchronous replication became very slow, especially when many sessions were working in parallel. It was discovered that the code to calculate this timeout was inside the wait loop itself, with the result that an increase in the value of rpl_semi_sync_master_timeout caused repeated iterations. This fix improves the method used to calculate wakeup times, and moves it outside of the wait loop, so that it is executed one time only. (Bug #16878043, Bug #69341)
- Replication: It was possible to cause a deadlock after issuing FLUSH TABLES WITH READ LOCK by issuing STOP SLAVE in a new connection to the slave, then issuing SHOW SLAVE STATUS using the original connection.
- The fix for this includes the addition of the rpl_stop_slave_timeout system variable, to control the time in seconds to wait for slave to stop after issuing STOP SLAVE before returning a warning. (Bug #16856735)
- Replication: Some expressions employing variables were not handled correctly by LOAD DATA. (Bug #16753869)
- Replication: In some circumstances, the message in the Last_Error column from the output of SHOW SLAVE STATUS referred to GTID_NEXT_LIST although this variable is not currently implemented (the name is reserved for possible future use). Now in such cases the error message no longer refers to this variable. (Bug #16742886, Bug #69096)
- References: See also Bug #16715809, Bug #69045.
- Replication: The error displayed by SHOW SLAVE STATUS when a worker thread fails to apply an event contained no event coordinate information. The GTID for the event's group was also not shown. Now in such cases, the text shown for Last_SQL_Error is prefixed with the (physical) master binary log coordinates, as well as the value of gtid_next when this has been set. (Bug #16594095)
- Replication: Linker errors occurred if the header file log_event.h was included in an application containing multiple source files, because the file rpl_tblmap.cc was included in log_event.h. This fix moves the inclusion of rpl_tblmap.cc into the source files that use log_event.h. (Bug #16607258)
- Replication: The warning issued when specifying MASTER_USER or MASTER_PASSWORD with CHANGE MASTER TO was unclear for a number of reasons, and has been changed to read, Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see 'START SLAVE Syntax' in the MySQL Manual for more information. (Bug #16460123, Bug #16461303, Bug #68602, Bug #68599)
- Replication: After a transaction was skipped due to its GTID already having been logged, all remaining executed transactions were incorrectly skipped until gtid_next was pointed to a different GTID.
- To avoid this incorrect behavior, all transactions—even those that have been skipped—are marked as undefined when they are commited or rolled back, so that an error is thrown whenever a second transaction is executed following the same SET @@session.gtid_next statement. (Bug #16223835)
- Replication: After the client thread on a slave performed a FLUSH TABLES WITH READ LOCK and was followed by some updates on the master, the slave hung when executing SHOW SLAVE STATUS. (Bug #68460, Bug #16387720)
- For debug builds, improper use of SAFE_MUTEX within dbug.c caused different code areas to have different ideas about size and contents of a mutex. This could result in out-of-bounds memory writes. (Bug #16945343)
- Sql_condition::set_subclass_origin() could perform an out-of-bounds read. (Bug #16969091)
- Initialization of keycache_* variables (see Multiple Key Caches) during server startup could write to incorrect memory. (Bug #16945503)
- Reads from message buffers for closed connections could occur. (Bug #17003702)
- The server could exit while using a cursor to fetch rows from a UNION query. (Bug #16983143)
- The range optimizer incorrectly assumed that any geometry function on a spatial index returned rows in ROWID order, which could result in incorrect query results. (Bug #16960800)
- The server did excessive locking on the LOCK_active_mi and active_mi->rli->data_lock mutexes for any SHOW STATUS LIKE 'pattern' statement, even when the pattern did not match status variables that use those mutexes (Slave_heartbeat_period, Slave_last_heartbeat, Slave_received_heartbeats, Slave_retried_transactions, Slave_running). Now attempts to show those variables do not lock those mutexes. This might result is slightly stale data, but better performance. (Bug #16904035)
- Full-text phrase search in InnoDB tables could read incorrect memory. (Bug #16885178)
- It was not possible to keep several major versions of MySQL in the same yum repository. (Bug #16878042)
- The Performance Schema could spawn a thread using incorrect instrumentation information. (Bug #16939689)
- INSERT ... ON DUPLICATE KEY UPDATE could cause a server exit if a column with no default value was set to DEFAULT. (Bug #16756402)
- References: This bug is a regression of Bug #14789787.
- The code base was modified to account for new warning checks introduced by gcc 4.8. (Bug #16729109)
- Compiling failed with -DMY_ATOMIC_MODE_RWLOCKS=1 or on platforms on which MySQL did not support lockless atomic operations (such as ARM). (Bug #16736461)
- In a prepared statement or stored routine, if the HAVING clause of a subquery referenced some column of the GROUP BY of the parent query, the server could exit. (Bug #16739050)
- The read-only open_files_limit system variable did not show maximum number of open files the mysqld process could have, but instead the number that was requested after adjusting the --open-files-limit command-line option. (Bug #16657588)
- Some rows for a session could be missing sporadically from the Performance Schema session_connect_attrs table while the session was executing a workload. (Bug #16576980)
- The server could make the wrong decision about whether an account password was expired. (Bug #16604641)
- Upgrading from community SLES RPM packages to commercial packages for the same MySQL version failed with conflict errors. (Bug #16545296)
- A full-text search syntax error failed to print to standard output. (Bug #16429688, Bug #16765397)
- Unlike MyISAM, InnoDB does not support boolean full-text searches on nonindexed columns, but this restriction was not enforced, resulting in queries that returned incorrect results. (Bug #16434374)
- If the optimizer was using a loose index scan, the server could exit while attempting to create a temporary table. (Bug #16436567)
- Incorrect results or a server exit could be caused by a reference to an aggregated expression inside a nested subquery, where the aggregated expression was evaluated in a query block more than two levels outer to the reference. (Bug #16436383)
- In debug builds, failure in the range optimizer for an ER_LOCK_DEADLOCK or ER_LOCK_WAIT_TIMEOUT error could go undetected and cause an assertion to be raised when a response was sent to the client. In release builds, this problem manifested as clients receiving an OK for a statement that had failed. (Bug #16366994, Bug #16247110)
- An assertion could be raised when creating a index on a prefix of a TINYBLOB column in an InnoDB column. (Bug #16368875)
- A server exit could occur for queries of the form SELECT (SELECT 1 FROM t1) IN (SELECT a FROM t1) when attempting to evaluate the constant left-hand argument to the IN subquery predicate. (Bug #16369522)
- No warning was generated if a duplicate index existed after dropping a column associated with a multiple-column index. (Bug #16315351)
- SELECT DISTINCT with WITH ROLLUP could result in a Duplicate entry 'NULL' for key '' error. (Bug #16314835)
- The server could exit in do_copy_not_null() due to an improper NULL-value check. (Bug #16316564)
- Transforming some subqueries that select temporal or BIGINT types or to a semijoin caused a server exit on the second execution of prepared statements or stored programs. (Bug #16319671)
- The usual failed-login attempt accounting was not applied to failed COM_CHANGE_USER commands. (Bug #16241992)
- A user variable referenced during execution of a prepared statement is set to memory that is freed at the end of execution. A second execution of the statement could result in Valgrind warnings when accessing this memory. (Bug #16119355)
- Misoptimization of left expressions in prepared statements could cause a server exit. (Bug #16095534)
- The optimizer trace could print ranges for key parts that were not usable for range access. (Bug #14615536)
- When running a query on INFORMATION_SCHEMA.INNODB_BUFFER_PAGE that requested table_name and index_name values, query results would include index pages without table_name or index_name values. (Bug #14529666)
- Several COM_xxx commands in the client-server protocol did not have length checks for incoming network packets, which could result in various problems for malformed input. (Bug #14525642)
- Passwords in statements were not obfuscated before being written to the audit log. (Bug #14536456)
- With the thread pool plugin in use, normal connection termination caused the Aborted_clients status variable to be incremented. (Bug #14081240)
- On Windows, command-line options of the form --opt_name="opt_value" worked but --opt_name='opt_value' did not.
- On all platforms, for Performance Schema options of the form --performance_schema_instrument="instrument=value", invalid instrument names now are rejected. (Bug #13955232)
- MySQL Installer, if run in custom install or change mode, offered installation options that had no effect. (Bug #12928601)
- Incorrect results could be returned from queries that used several aggr_func(DISTINCT) functions (where aggr_func() is an aggregate function such as COUNT()) when these referred to different columns of the same composite key. (Bug #12328597)
- If an UPDATE containing a subquery caused a deadlock inside InnoDB, the deadlock was not properly handled by the SQL layer. The SQL layer then tried to unlock the row after InnoDB rolled back the transaction, raising an assertion inside InnoDB. (Bug #69127, Bug #16757869)
- Boolean plugin system variables did not behave well on machines where char is unsigned; some code attempted to assign a negative value to these. (Bug #59905, Bug #11864205)
- In the absence of SQL_CALC_FOUND_ROWS in the preceding query, FOUND_ROWS() should return the number of rows in the result set, but this did not always happen if the query contained ORDER BY. (Bug #69271, Bug #16827872)
- Unoptimized versions of the xxxkorr() macros in my_global.h were used on 64-bit x86 processors. (Bug #61179, Bug #12565703)
- sql-common/client_plugin.c contained a nonportable use of a va_list parameter. (Bug #62769, Bug #13252623)
- mysqldump assumed the existence of the general_log and slow_log tables in the mysql database. It failed if invoked to dump tables from an older server where these tables do not exist. (Bug #65670, Bug #14236170)
- Full-text search on InnoDB tables failed on searches for words containing apostrophes. (Bug #69216, Bug #16801781)
- Full-text search on InnoDB tables failed on searches for literal phrases combined with + or - operators. (Bug #68720, Bug #16516193)
- Optimizations that used extended secondary keys (see Use of Index Extensions) worked only for InnoDB, even for storage engines with the requisite underlying capabilities. (Bug #68469, Bug #16391678)
- With big_tables enabled, queries that used COUNT(DISTINCT) on a simple join with a constant equality condition on a non-duplicate key returned incorrect results. (Bug #52582, Bug #11760197)
- mysql_install_db incorrectly tried to create the mysql.innodb_table_stats and mysql.innodb_index_stats tables if InnoDB was not available. (Bug #68438, Bug #16369955)
- If one session had any metadata lock on a table, another session attempting CREATE TABLE [IF NOT EXISTS] for the same table would hang. This occurred due to an attempt in the second session to acquire an exclusive metadata lock on the table before checking whether the table already existed. An exclusive metadata lock is not compatible with any other metadata locks, so the session hung for the lock timeout period if another session had the table locked.
- Now the server attempts to acquire a shared metadata lock on the table first to check whether it exists, then upgrade to an exclusive lock if it does not. If the table does exist, an error occurs for CREATE TABLE and a warning for CREATE TABLE IF NOT EXISTS. (Bug #63144, Bug #13418638)
- Attempts to build from a source RPM package could fail because the build process attempted to refer to a pb2user that might not exist. (Bug #64641, Bug #13865797, Bug #69339, Bug #16874980)
- A typo in cmake/dtrace.cmake prevented DTrace support from being enabled by -DENABLE_DTRACE-on. (Bug #60743, Bug #12325449)
- When an internal buffer was too small for the workload, the Performance Schema could spend a lot of time in an internal spin loop attempting to allocate a memory buffer, and fail. (Bug #69382, Bug #16945618)
- Some LEFT JOIN queries with GROUP BY could return incorrect results. (Bug #68897, Bug #16620047)
- References: This bug is a regression of Bug #11760517.
- For queries with ORDER BY ... LIMIT, the optimizer could choose a nonordering index for table access. (Bug #69410, Bug #16916596)
- When selecting a union of an empty result set (created with WHERE 1=0 or WHERE FALSE) with a derived table, incorrect filtering was applied to the derived table. (Bug #69471, Bug #16961803)
- References: This bug is a regression of Bug #15848521.
- Comparison of a DATETIME value and a string did not work correctly for the utf8_unicode_ci collation. (Bug #68795, Bug #16567381)

更新時間：2013-06-05
更新細節：

What's new in this version:

Functionality Added or Changed:
- mysql_upgrade now verifies that the server version matches the version against which it was compiled, and exits if there is a mismatch. In addiion, a --version-check option permits specifying whether to enable version checking (the default), or disable checking if given as --skip-version-checking. Bugs Fixed:
- Incompatible Change: When used for an existing MySQL account, the GRANT statement could produce unexpected reults if it included an IDENTIFIED WITH clause that named an authentication plug differing from the plugin named in the corresponding mysql.user table row.
- Because IDENTIFIED WITH is intended for GRANT statements that create a new user, it is now prohibited if the named account already exists.
- Important Change; Replication: When the server was running with --binlog-ignore-db and SELECT DATABASE() returned NULL (that is, there was no currently selected database), statements using fully qualified table names in dbname.tblname format were not written to the binary log. This was because the lack of a currently selected database in such cases was treated as a match for any possible ignore option rather than for no such option; this meant that these statements were always ignored.
- Now, if there is no current database, a statement using fully qualified table names is always written to the binary log.
- InnoDB; Partitioning: Joins involving partitioned InnoDB tables having one or more BLOB columns were not always handled correctly. The BLOB column or columns were not required to be join columns, or otherwise to be named or referenced in the statement containing the join, for this issue to occur.
- InnoDB: In debug builds, an online ALTER TABLE operation that performed a full table copy would raise an assertion. The assertion was due to a race condition that would occur during BLOB retrieval, when applying the table modification log to any log block except for the very last one. This fix modifies row_log_table_apply_convert_mrec() to ensure that an index B-tree lock is acquired to protect the access to log->blobs and the BLOB page.
- InnoDB: When the function trx_rollback_or_clean_recovered() rolls back or cleans up transactions during a crash recovery, it removes the trx objects from the trx_sys list without freeing up the memory used by those objects. To prevent a memory leak, this fix adds trx_free_for_background() calls to trx_rollback_resurrected(), the function that removes the trx objects.
- InnoDB: A missing comma in SHOW STATUS output would break MySQL Enterprise Monitor parsing.
- InnoDB: After a clean shutdown, InnoDB does not check .ibd file headers at startup. As a result, in a crash recovery scenario, InnoDB could load a corrupted tablespace file. This fix implements consistency and status checks to avoid loading corrupted files.
- InnoDB: A memory leak would occur in dict_check_tablespaces_and_store_max_id() when space_id is equal to zero.
- InnoDB: When ADD PRIMARY KEY columns are reordered in an ALTER TABLE statement (for example: ALTER TABLE t1 ADD PRIMARY KEY(a,b), CHANGE a a INT AFTER b), the log apply for UPDATE operations would fail to find rows.
- InnoDB: DML operations on compressed temporary tables would result in a Valgrind error in the buffer manager stack.
- InnoDB: This fix addresses a race condition that would occur between the rollback of a recovered transaction and creation of a secondary index in a locked operation. The race condition would corrupt the secondary index.
- InnoDB: For ALTER TABLE operations on InnoDB tables that required a table-copying operation, other transactions on the table might fail during the copy. However, if such a transaction issued a partial rollback, the rollback was treated as a full rollback.
- InnoDB: Under certain circumstances, LRU flushing would take a long time possibly affecting all flushing activity and causing a shutdown timeout.
- InnoDB: The recv_writer thread would only start after all redo log scans finished. In the case of multiple redo log scans, accumulated redo records would be applied after each scan and before processing the next scan. The absence of the recv_writer thread to help with flushing would slow recovery or result in a server startup timeout. This fix ensures that the recv_writer thread starts before the first scan batch is processed.
- InnoDB: This fix replaces the IB_ULONGLONG_MAX constant with LSN_MAX where the code refers to log sequence numbers, or with TRX_ID_MAX where trx->no is initialized to an undefined value. This change does not alter the value of the constant.
- InnoDB: This fix corrects the text for InnoDB error 6025, which stated, “InnoDB: read can't be opened in ./ib_logfile0 mode.”. The corrected message states, “InnoDB: ./ib_logfile0 can't be opened in read mode.” The variable and mode in the message construct were transposed.
- InnoDB: The page_zip_available function would count some fields twice.
- InnoDB: This fix removes most calls to OS_THREAD_SLEEP from InnoDB.
- InnoDB: Concurrently inserting into a full-text table would cause some inserts to fail. Duplicate values would be generated for full-text search document IDs when performing inserts into a hidden full-text search document ID column.
- InnoDB: FLUSH TABLES FOR EXPORT would sleep too often while flushing pages from buffer pools.
- InnoDB: In cases where threads are forced to do single page flushing, fsync() would be triggered for all data files. This fix allows for synchronous single page flushing.
- InnoDB: In debug builds, an insert would fail with an invalid assertion: sync_thread_levels_g(array, level - 1, TRUE).
- InnoDB: Multiple concurrent calls to dict_update_statistics() would result in unnecessary server load.
- InnoDB: On 64-bit Windows builds, INNODB_BUFFER_POOL_SIZE would not accept an allocation of more than 32GB. This limitation was due to a bug that truncated the internal value for the InnoDB buffer pool size to 32 bits on 64-bit Windows builds.
- InnoDB: Crash recovery would fail with a !recv_no_log_write assertion when reading a page.
- InnoDB: Creating a foreign key constraint using the ALTER TABLE INPLACE algorithm requires foreign_key_checks to be set to 0 (SET foreign_key_checks = 0;). As a result, an appropriate duplicate ID check would not be performed.
- InnoDB: RENAME TABLE would result in a hang due to a MySQL mutex acquisition deadlock.
- InnoDB: DROP DATABASE failed if the database contained an InnoDB table that had a data file in an external data directory. The external data file had an “InnoDB Symbolic Link” file type (.isl) that was not recognized by MySQL. This fix adds .isl as a known InnoDB file type.
- InnoDB: When tables are linked by foreign key constraints, loading one table would open other linked tables recursively. When numerous tables are linked by foreign key constraints, this would sometimes lead to a thread stack overflow causing the server to exit. Tables linked by foreign key constraints are now loaded iteratively. Cascade operations, which were also performed in a recursive manner, are now performed iteratively using an explicit stack.
- InnoDB: When calling the lock_rec_block_validate() function after releasing the kernel mutex, there is a chance the lock might be invalid and result in a Valgrind error due to an invalid read on lock->index. This fix copies the lock->index when the kernel mutex is being held and passes the lock->index to lock_rec_block_validate().
- InnoDB: Under testing, a FLUSH TABLE operation resulted in a timeout due to a missing acknowledgement that the purge thread had stopped.
- InnoDB: For a compressed table, the “page reorganize” function would ignore the innodb_log_compressed_pages option and always log the entire compressed page, which increased the size of the redo log. The “page reorganize” function now adheres to the innodb_log_compressed_pages option and does not log compressed page images to the redo log when innodb_log_compressed_pages is set to “OFF”.
- InnoDB: After disabling foreign key checks with SET foreign_key_checks=0 and performing a DROP INDEX, the table was no longer accessible after restarting the server. This fix allows the table with missing foreign key indexes to be accessed when SET foreign_key_checks=0. When the table is accessible, the user must recreate the missing indexes to fulfill the foreign key constraints.
- InnoDB: When a transaction is in READ COMMITTED isolation level, gap locks are still taken in the secondary index when a row is inserted. This occurs when the secondary index is scanned for duplicates. The function row_ins_scan_sec_index_for_duplicate() always calls the function row_ins_set_shared_rec_lock() with LOCK_ORDINARY irrespective of the transaction isolation level. This fix modifies the row_ins_scan_sec_index_for_duplicate() function to call row_ins_set_shared_rec_lock() with LOCK_ORDINARY or LOCK_REC_NOT_GAP, based on the transaction isolation level.
- InnoDB: Starting mysqld with --innodb_log_buffer_size=50GB failed to allocate memory and returned NULL. For non-debug builds there was no check in place and a segmentation fault occurred. This fix adds a log message stating that memory failed to be allocated, and adds an assertion.
- InnoDB: When UNIV_DEBUG is enabled in debug builds, buf_validate() is often called which sometimes results in false alarms in tests on semaphore wait timeout. This fix increases counter values to reduce false alarms.
- InnoDB: While processing read-write workloads, InnoDB would scan more pages than are required for flushing, unnecessarily consuming CPU resource.
- InnoDB: The explain_filename function, which provides information about a partition by parsing the file name, would return an error when attempting to parse a file name with no partition information.
- InnoDB: Stopping the server, removing a database table (d1.t1) .frm file from the data directory, restarting the server, and dropping the database (d1), would cause an assertion.
- InnoDB: An active FLUSH TABLE FOR EXPORT thread would cause a hang during shutdown. The fix ensures that trx_is_interrupted() is checked during ibuf_merge.
- InnoDB: A multi-row INSERT ... ON DUPLICATE KEY UPDATE insert failure, caused by a duplicate key error, would result in duplicate auto-increment values.
- Replication: Point-in-time recovery could fail when trying to restore a single database from a binary log in row-based format using mysqlbinlog with the --database option.
- Replication: Issuing a FLUSH TABLES statement on a GTID-enabled master caused replication to fail. It was found that this misbehavior was introduced by the fix for Bug #16062608, which disallowed statements that perform an implicit commit but whose changes are not logged when gtid_next is set to any value other than AUTOMATIC. The changes made in that fix have been reverted, and such statements are (again) allowed without regard to the value of this variable.
- Replication: A crash-on-commit error caused InnoDB to lose the previous transaction following execution of a RESET MASTER statement. This occurred because the prepare phase caused a flush to disk, while the commit phase did not perform a corresponding flush within InnoDB.
- To fix this problem, RESET MASTER now causes storage engine logs to be flushed on commit.
- Replication: When used with the options --dump-slave --include-master-host-port, mysqldump printed the port number within quotation marks, as if it were a string value rather than an integer.
- Replication: When processing an Update_rows_log_event or Delete_rows_log_event from the binary log, the before image is hashed and stored in a hash table. Following this, the original table is scanned for the desired records; subsequent processing hashes each record fetched from the original table and performs a lookup for it in the hash table. However, columns read from the image that had originally been set to NULL could instead contain random or “garbage” data, causing the lookup (and thus replication) to fail with an error such as Could not execute Update_rows event on table.
- Replication: Due to time resolution issues on some systems, the time to be taken by the dump thread for a reply from the slave could be calculated to be less than zero, leading to Semi-sync master wait for reply fail to get wait time errors. Since this condition does not have a negative impact on replication, errors caused by these conditions have been reduced to warnings.
- Replication: When one or more GTID log events but no previous GTIDs log events were found in the binary log, the resulting error was mishandled and led to a failure of the server. (This is an extremely rare condition that should never occur under normal circumstances, and likely indicates that the binary log file has somehow been corrupted.) Now in such cases, an appropriate error is issued, and is handled correctly.
- Replication: Running the server with both the --log-slave-updates and --replicate-wild-ignore-table options in some cases caused updates to user variables not to be logged.
- Replication: When using mysqlbinlog and the mysql client to roll forward two or more binary logs on a server having GTIDs enabled, the gtid_next variable was not properly reset when switching from the first to the second binary log, causing processing to halt with an error at that point.
- Replication: The mysqlbinlog options --include-gtids, --exclude-gtids, and --skip-gtids did not work correctly when trying to process multiple files.
- Replication: When the size of an execution event exceeded the maximum set for the buffer (slave_pending_jobs_size_max), row-based replication could hang with Waiting for slave workers to free pending events.
- Replication: Extra binary log rotations were performed due to concurrent attempts at rotation when the binary log became full, which were allowed to succeed. This could lead to the unnecessary creation of many small binary log files.
- Replication: Attempting to execute START SLAVE after importing new slave_master_info and slave_relay_log_info tables failed with an empty error message. Now an appropriate error and message are issued in such cases.
- Replication: Restarting the server after the slave_relay_log_info table had been emptied caused mysqld to fail while trying to return an error.
- Replication: Following disconnection from the master, the slave could under certain conditions report erroneously on reconnection that it had received a packet that was larger than slave_max_allowed_packet, causing replication to fail.
- Replication: An SQL thread error during MTS slave recovery caused the slave to fail.
- Replication: When using the options --read-from-remote-server --stop-never --base64-output=decode-rows --verbose, mysqlbinlog failed to reset the counter used to store the current position within the file when the binary log on the server was rotated.
- Replication: When using mysqldump to back up a database created with MySQL 5.6.4 or an earlier version, setting --set-gtid-purged=AUTO caused the backup to fail, because pre-5.6.5 versions of MySQL did not support GTIDs, and it could not be determined if GTIDs were enabled for the database. This fix makes sure mysqldump does not attempt to output a SET @@global.gtid_purged statement when backing up any pre-5.6.5 databases.
- Replication: Deadlocks could sometimes occur on group commits with a high number of concurrent updates, as well as when one client held a lock from a commit while another client imposed a lock while rotating the binary log.
- Replication: When semisynchronous replication was enabled, the automatic dropping on the master of an event created using ON COMPLETION NOT PRESERVE caused the master to fail.
- Replication: Setting a SET column to NULL inside a stored procedure caused replication to fail.
- Replication: The binary log contents got corrupted sometimes, because the function MYSQL_BIN_LOG::write_cache always thought it had reached the end-of-cache when the function my_b_fill() reported a '0,' while that could also mean an error had occurred. This fix makes sure that whenever my_b_fill() returns a '0,' an error check is performed on info->error.
- Replication: PURGE BINARY LOGS by design does not remove binary log files that are in use or active, but did not provide any notice when this occurred. Now, when log files are not removed under such conditions, a warning is issued; this warning includes information about the file or files were not removed when the statement was issued.
- Replication: When replicating to a BLACKHOLE table using the binary logging format, updates and deletes cannot be applied and so are skipped. Now a warning is generated for this whenever it occurs. Note:
- binlog_format=STATEMENT is recommended when replicating to tables that use the BLACKHOLE storage engine.
- Removing a server RPM package did not shut down the existing server if it was running.
- Overhead for setting PROCESSLIST_STATE values in the Performance Schema THREADS table has been reduced.
- The Windows authentication plugin failed to free a context buffer for each connection.
- The DBUG_PRINT() macro unnecessarily evaluated arguments when debugging was not enabled.
- When index condition pushdown was used on a descending range scan and the first range interval did not contain any qualifying records, the result of the range scan could be empty even if other range intervals contained qualifying records.
- The server could attempt a filesort operation for a zero-size sort length, causing it to exit.
- my_load_defaults() was modified to accommodate some problems under compilation with gcc 4.7.2 that could cause a client crash during option processing.
- Opening a cursor on a SELECT within a stored procedure could cause a segmentation fault.
- SET PASSWORD treated user@'%' and user@'' as referring to the same mysql.user table row.
- Geometry methods that worked with WKB data performed insufficient input data validation, which could cause Valgrind errors or a server exit.
- Some INFORMATION_SCHEMA queries that used ORDER BY did not use a filesort optimization as they did in MySQL 5.5. (Bug #16423536)
- Performance Schema parameter autosizing at startup did not take into account later autosizing changes to other startup parameters on which the Performance Schema parameters depended.
- The WKB reader for spatial operations could fail and cause a server exit.
- Optimizer heuristics inappropriately preferred range access over ref access in cases when the ref access referred to a column of a table earlier in the join seqence.
- Manually-created accounts (using INSERT) with a malformed password effectively had no password.
- Several scripts in the sql-bench directory that were supposed to be executable did not have the executable access bit set.
- For debug builds, DBUG_EXPLAIN resulted in a buffer overflow when the debug system variable value was more than 255 characters.
- Within an XA transaction in ACTIVE state, statements causing an implicit commit could result in metadata locks being released too early.
- Installing Debian packages on Ubuntu 12.10 succeeded using dpkg, but not with Software Center 5.4.1.4.
- For debug builds, with an XA transaction in IDLE or PREPARED status, execution of a query with the query cache enabled could cause a server exit.
- thread_pool_high_priority_connection could not be set at server startup.
- Re-execution of a stored procedure could cause a server exit in Item_field::fix_outer_field.
- A GROUP_CONCAT() invocation containing subquery having an outer reference caused the server to exit.
- With secure_auth enabled, a user with a password that used the pre-4.1 (old) hashing could not update it to use the 4.1 (new) hashing.
- For debug builds, GROUP_CONCAT(... ORDER BY) within an ORDER BY clause could cause a server exit.
- The validate_password plugin did not always enforce appropriate constraints against assigning empty passwords.
- For debug builds, the server could exit for queries involving a nested subquery, a subquery tranformed into a semi-join and using a view.
- The range optimizer could set up incorrect ranges for queries that used XOR operations.
- mysql_secure_installation could not connect to the server if the account used had an expired password. It invoked mysql noninteractively, resulting in that program failing to connect. Now mysql supports a --connect-expired-password option that indicates to the server that it can handle sandbox mode for expired-password accounts even if invoked noninteractively, and mysql_secure_installation invokes mysql with this option.
- If loose index scan was used on a query that used MIN(), a segmentation fault could occur.
- If multiple statements were sent in a single request, the audit log plugin logged only the last one. Now it logs each statement separately.
- For debug builds, an assertion was incorrectly raised for queries executed using eq_ref access and filesort.
- An outer join between a regular table and a derived table that is implicitly groups could cause a server exit.
- A prepared statement that used GROUP_CONCAT() and an ORDER BY clause that named multiple columns could cause the server to exit.
- Creating a FEDERATED table without specifying a connection string caused a server exit. ORDER BY MATCH ... AGAINST could cause a server exit.
- Client programs from MySQL 5.6.4 and up could confuse older servers during the connection process by using newer protocol features not understood by older servers.
- When a partition is missing, code in ha_innodb.cc would retry 10 times and sleep for a microsecond each time while holding LOCK_open. The retry logic for partitioned tables was introduced as a fix for Bug#33349 but did not include a test case to validate it. This fix removes the retry logic for partitioned tables. If the problem reported in Bug#33349 reappears, a different solution will be explored.
- The mysql.server script exited with an error if the status command was executed with multiple servers running.
- Use of the VALUES() function in the VALUES() clause of an INSERT statement could result in Valgrind warnings or an unstable server, possibly leading to a server exit.
- In some cases, REVOKE could fail to revoke the GRANT OPTION privilege.
- The mysql client allocated but did not free a string after reading each line in interactive mode, resulting in a memory leak.
- Killing a connection while it was in the process of disconnecting could lead to an assertion being raised, Valgrind warnings, and general unstability.
- INSERT ... ON DUPLICATE KEY UPDATE on a view could cause a server exit. (Bug #14261010)
- Grouping by an outer BLOB column in a subquery caused a server exit.
- The server could exit due to improper handling of the error from an invalid comparison.
- The CMake check for unsigned time_t failed on all platforms.
- mysqladmin debug causes the server to write debug information to the error log. On systems that supported mallinfo(), the memory-status part of this output was incorrect in 64-bit environments when mysqld consumed more than 4GB memory.
- Now the server uses malloc_info() to obtain memory-status information. malloc_info() does not report the memory that the glibc malloc() implementation internally allocates using mmap(). However, it does provide the memory usage information in all the memory arenas.
- This bug fix also involves a change of output format. The server now writes memory information in XML format rather than as plain text.
- The mysql client incorrectly used latin1 for certain comparisons even if started with a multibyte default character set, resulting in a client crash.
- The url columns in the mysql datatbase help tables were too short to hold some of the URLs in the help content. These columns are now created as type TEXT to accommodate longer URLs.
- mysqld --help and mysqld --verbose --help performed unnecessary logging.
- InnoDB does not support full-text parser plugins, but failed to report an error if they were specified. Now an ER_INNODB_NO_FT_USES_PARSER error is returned.
- If Loose Index Scan was used to evaluate a query that compared an integer column to an integer specified as a quoted string (for example, col_name = '1'), the query could return incorrect results.
- IF() function evaluations could produce different results when executed in a prepared versus nonprepared statement.
- If a function such as AES_DECRYPT() that requires SSL support failed, the error could affect later calls to functions that require SSL support.
- In a MySQL server newer than MySQL 5.5 using a nonupgraded mysql.user table (for which mysql_upgrade had not been run), statements to set passwords caused a server exit due to a faulty check for the password_expired column.
- It is now possible to suppress installation of the mysql-test directory after compiling MySQL from source by invoking CMake with the INSTALL_MYSQLTESTDIR option explicitly set to empty:
- cmake . -DINSTALL_MYSQLTESTDIR=. Previously, attempts to do this resulted in an error.
- When only counting events but not timing them, Performance Schema would report MIN_TIMER_WAIT values as a large number instead of 0.
- Using range access with an index prefix could produce incorrect results.
- For debug builds, metadata locking for CREATE TABLE ... SELECT could raise an assertion.
- A new CMake option, WITH_EDITLINE, is provided to indicate whether to use the bundled or system libedit/editline library. The permitted values are bundled (the default) and system.
- WITH_EDITLINE replaces WITH_LIBEDIT, which has been removed.
- When specified in an option file, the plugin-dir client option was ignored.
- Indexes on derived tables that were used during the first invocation of a stored procedure were not used in subsequent invocations.
- For DELETE and UPDATE statements, EXPLAIN displayed NULL in the ref column for some cases where const is more appropriate.
- The optimizer could choose a poor execution plan for queries with ORDER BY ... LIMIT.
- FOUND_ROWS() could return an incorrect value if the preceding query used filesort

更新時間：2013-06-05
更新細節：

What's new in this version:

Functionality Added or Changed:
- mysql_upgrade now verifies that the server version matches the version against which it was compiled, and exits if there is a mismatch. In addiion, a --version-check option permits specifying whether to enable version checking (the default), or disable checking if given as --skip-version-checking. Bugs Fixed:
- Incompatible Change: When used for an existing MySQL account, the GRANT statement could produce unexpected reults if it included an IDENTIFIED WITH clause that named an authentication plug differing from the plugin named in the corresponding mysql.user table row.
- Because IDENTIFIED WITH is intended for GRANT statements that create a new user, it is now prohibited if the named account already exists.
- Important Change; Replication: When the server was running with --binlog-ignore-db and SELECT DATABASE() returned NULL (that is, there was no currently selected database), statements using fully qualified table names in dbname.tblname format were not written to the binary log. This was because the lack of a currently selected database in such cases was treated as a match for any possible ignore option rather than for no such option; this meant that these statements were always ignored.
- Now, if there is no current database, a statement using fully qualified table names is always written to the binary log.
- InnoDB; Partitioning: Joins involving partitioned InnoDB tables having one or more BLOB columns were not always handled correctly. The BLOB column or columns were not required to be join columns, or otherwise to be named or referenced in the statement containing the join, for this issue to occur.
- InnoDB: In debug builds, an online ALTER TABLE operation that performed a full table copy would raise an assertion. The assertion was due to a race condition that would occur during BLOB retrieval, when applying the table modification log to any log block except for the very last one. This fix modifies row_log_table_apply_convert_mrec() to ensure that an index B-tree lock is acquired to protect the access to log->blobs and the BLOB page.
- InnoDB: When the function trx_rollback_or_clean_recovered() rolls back or cleans up transactions during a crash recovery, it removes the trx objects from the trx_sys list without freeing up the memory used by those objects. To prevent a memory leak, this fix adds trx_free_for_background() calls to trx_rollback_resurrected(), the function that removes the trx objects.
- InnoDB: A missing comma in SHOW STATUS output would break MySQL Enterprise Monitor parsing.
- InnoDB: After a clean shutdown, InnoDB does not check .ibd file headers at startup. As a result, in a crash recovery scenario, InnoDB could load a corrupted tablespace file. This fix implements consistency and status checks to avoid loading corrupted files.
- InnoDB: A memory leak would occur in dict_check_tablespaces_and_store_max_id() when space_id is equal to zero.
- InnoDB: When ADD PRIMARY KEY columns are reordered in an ALTER TABLE statement (for example: ALTER TABLE t1 ADD PRIMARY KEY(a,b), CHANGE a a INT AFTER b), the log apply for UPDATE operations would fail to find rows.
- InnoDB: DML operations on compressed temporary tables would result in a Valgrind error in the buffer manager stack.
- InnoDB: This fix addresses a race condition that would occur between the rollback of a recovered transaction and creation of a secondary index in a locked operation. The race condition would corrupt the secondary index.
- InnoDB: For ALTER TABLE operations on InnoDB tables that required a table-copying operation, other transactions on the table might fail during the copy. However, if such a transaction issued a partial rollback, the rollback was treated as a full rollback.
- InnoDB: Under certain circumstances, LRU flushing would take a long time possibly affecting all flushing activity and causing a shutdown timeout.
- InnoDB: The recv_writer thread would only start after all redo log scans finished. In the case of multiple redo log scans, accumulated redo records would be applied after each scan and before processing the next scan. The absence of the recv_writer thread to help with flushing would slow recovery or result in a server startup timeout. This fix ensures that the recv_writer thread starts before the first scan batch is processed.
- InnoDB: This fix replaces the IB_ULONGLONG_MAX constant with LSN_MAX where the code refers to log sequence numbers, or with TRX_ID_MAX where trx->no is initialized to an undefined value. This change does not alter the value of the constant.
- InnoDB: This fix corrects the text for InnoDB error 6025, which stated, “InnoDB: read can't be opened in ./ib_logfile0 mode.”. The corrected message states, “InnoDB: ./ib_logfile0 can't be opened in read mode.” The variable and mode in the message construct were transposed.
- InnoDB: The page_zip_available function would count some fields twice.
- InnoDB: This fix removes most calls to OS_THREAD_SLEEP from InnoDB.
- InnoDB: Concurrently inserting into a full-text table would cause some inserts to fail. Duplicate values would be generated for full-text search document IDs when performing inserts into a hidden full-text search document ID column.
- InnoDB: FLUSH TABLES FOR EXPORT would sleep too often while flushing pages from buffer pools.
- InnoDB: In cases where threads are forced to do single page flushing, fsync() would be triggered for all data files. This fix allows for synchronous single page flushing.
- InnoDB: In debug builds, an insert would fail with an invalid assertion: sync_thread_levels_g(array, level - 1, TRUE).
- InnoDB: Multiple concurrent calls to dict_update_statistics() would result in unnecessary server load.
- InnoDB: On 64-bit Windows builds, INNODB_BUFFER_POOL_SIZE would not accept an allocation of more than 32GB. This limitation was due to a bug that truncated the internal value for the InnoDB buffer pool size to 32 bits on 64-bit Windows builds.
- InnoDB: Crash recovery would fail with a !recv_no_log_write assertion when reading a page.
- InnoDB: Creating a foreign key constraint using the ALTER TABLE INPLACE algorithm requires foreign_key_checks to be set to 0 (SET foreign_key_checks = 0;). As a result, an appropriate duplicate ID check would not be performed.
- InnoDB: RENAME TABLE would result in a hang due to a MySQL mutex acquisition deadlock.
- InnoDB: DROP DATABASE failed if the database contained an InnoDB table that had a data file in an external data directory. The external data file had an “InnoDB Symbolic Link” file type (.isl) that was not recognized by MySQL. This fix adds .isl as a known InnoDB file type.
- InnoDB: When tables are linked by foreign key constraints, loading one table would open other linked tables recursively. When numerous tables are linked by foreign key constraints, this would sometimes lead to a thread stack overflow causing the server to exit. Tables linked by foreign key constraints are now loaded iteratively. Cascade operations, which were also performed in a recursive manner, are now performed iteratively using an explicit stack.
- InnoDB: When calling the lock_rec_block_validate() function after releasing the kernel mutex, there is a chance the lock might be invalid and result in a Valgrind error due to an invalid read on lock->index. This fix copies the lock->index when the kernel mutex is being held and passes the lock->index to lock_rec_block_validate().
- InnoDB: Under testing, a FLUSH TABLE operation resulted in a timeout due to a missing acknowledgement that the purge thread had stopped.
- InnoDB: For a compressed table, the “page reorganize” function would ignore the innodb_log_compressed_pages option and always log the entire compressed page, which increased the size of the redo log. The “page reorganize” function now adheres to the innodb_log_compressed_pages option and does not log compressed page images to the redo log when innodb_log_compressed_pages is set to “OFF”.
- InnoDB: After disabling foreign key checks with SET foreign_key_checks=0 and performing a DROP INDEX, the table was no longer accessible after restarting the server. This fix allows the table with missing foreign key indexes to be accessed when SET foreign_key_checks=0. When the table is accessible, the user must recreate the missing indexes to fulfill the foreign key constraints.
- InnoDB: When a transaction is in READ COMMITTED isolation level, gap locks are still taken in the secondary index when a row is inserted. This occurs when the secondary index is scanned for duplicates. The function row_ins_scan_sec_index_for_duplicate() always calls the function row_ins_set_shared_rec_lock() with LOCK_ORDINARY irrespective of the transaction isolation level. This fix modifies the row_ins_scan_sec_index_for_duplicate() function to call row_ins_set_shared_rec_lock() with LOCK_ORDINARY or LOCK_REC_NOT_GAP, based on the transaction isolation level.
- InnoDB: Starting mysqld with --innodb_log_buffer_size=50GB failed to allocate memory and returned NULL. For non-debug builds there was no check in place and a segmentation fault occurred. This fix adds a log message stating that memory failed to be allocated, and adds an assertion.
- InnoDB: When UNIV_DEBUG is enabled in debug builds, buf_validate() is often called which sometimes results in false alarms in tests on semaphore wait timeout. This fix increases counter values to reduce false alarms.
- InnoDB: While processing read-write workloads, InnoDB would scan more pages than are required for flushing, unnecessarily consuming CPU resource.
- InnoDB: The explain_filename function, which provides information about a partition by parsing the file name, would return an error when attempting to parse a file name with no partition information.
- InnoDB: Stopping the server, removing a database table (d1.t1) .frm file from the data directory, restarting the server, and dropping the database (d1), would cause an assertion.
- InnoDB: An active FLUSH TABLE FOR EXPORT thread would cause a hang during shutdown. The fix ensures that trx_is_interrupted() is checked during ibuf_merge.
- InnoDB: A multi-row INSERT ... ON DUPLICATE KEY UPDATE insert failure, caused by a duplicate key error, would result in duplicate auto-increment values.
- Replication: Point-in-time recovery could fail when trying to restore a single database from a binary log in row-based format using mysqlbinlog with the --database option.
- Replication: Issuing a FLUSH TABLES statement on a GTID-enabled master caused replication to fail. It was found that this misbehavior was introduced by the fix for Bug #16062608, which disallowed statements that perform an implicit commit but whose changes are not logged when gtid_next is set to any value other than AUTOMATIC. The changes made in that fix have been reverted, and such statements are (again) allowed without regard to the value of this variable.
- Replication: A crash-on-commit error caused InnoDB to lose the previous transaction following execution of a RESET MASTER statement. This occurred because the prepare phase caused a flush to disk, while the commit phase did not perform a corresponding flush within InnoDB.
- To fix this problem, RESET MASTER now causes storage engine logs to be flushed on commit.
- Replication: When used with the options --dump-slave --include-master-host-port, mysqldump printed the port number within quotation marks, as if it were a string value rather than an integer.
- Replication: When processing an Update_rows_log_event or Delete_rows_log_event from the binary log, the before image is hashed and stored in a hash table. Following this, the original table is scanned for the desired records; subsequent processing hashes each record fetched from the original table and performs a lookup for it in the hash table. However, columns read from the image that had originally been set to NULL could instead contain random or “garbage” data, causing the lookup (and thus replication) to fail with an error such as Could not execute Update_rows event on table.
- Replication: Due to time resolution issues on some systems, the time to be taken by the dump thread for a reply from the slave could be calculated to be less than zero, leading to Semi-sync master wait for reply fail to get wait time errors. Since this condition does not have a negative impact on replication, errors caused by these conditions have been reduced to warnings.
- Replication: When one or more GTID log events but no previous GTIDs log events were found in the binary log, the resulting error was mishandled and led to a failure of the server. (This is an extremely rare condition that should never occur under normal circumstances, and likely indicates that the binary log file has somehow been corrupted.) Now in such cases, an appropriate error is issued, and is handled correctly.
- Replication: Running the server with both the --log-slave-updates and --replicate-wild-ignore-table options in some cases caused updates to user variables not to be logged.
- Replication: When using mysqlbinlog and the mysql client to roll forward two or more binary logs on a server having GTIDs enabled, the gtid_next variable was not properly reset when switching from the first to the second binary log, causing processing to halt with an error at that point.
- Replication: The mysqlbinlog options --include-gtids, --exclude-gtids, and --skip-gtids did not work correctly when trying to process multiple files.
- Replication: When the size of an execution event exceeded the maximum set for the buffer (slave_pending_jobs_size_max), row-based replication could hang with Waiting for slave workers to free pending events.
- Replication: Extra binary log rotations were performed due to concurrent attempts at rotation when the binary log became full, which were allowed to succeed. This could lead to the unnecessary creation of many small binary log files.
- Replication: Attempting to execute START SLAVE after importing new slave_master_info and slave_relay_log_info tables failed with an empty error message. Now an appropriate error and message are issued in such cases.
- Replication: Restarting the server after the slave_relay_log_info table had been emptied caused mysqld to fail while trying to return an error.
- Replication: Following disconnection from the master, the slave could under certain conditions report erroneously on reconnection that it had received a packet that was larger than slave_max_allowed_packet, causing replication to fail.
- Replication: An SQL thread error during MTS slave recovery caused the slave to fail.
- Replication: When using the options --read-from-remote-server --stop-never --base64-output=decode-rows --verbose, mysqlbinlog failed to reset the counter used to store the current position within the file when the binary log on the server was rotated.
- Replication: When using mysqldump to back up a database created with MySQL 5.6.4 or an earlier version, setting --set-gtid-purged=AUTO caused the backup to fail, because pre-5.6.5 versions of MySQL did not support GTIDs, and it could not be determined if GTIDs were enabled for the database. This fix makes sure mysqldump does not attempt to output a SET @@global.gtid_purged statement when backing up any pre-5.6.5 databases.
- Replication: Deadlocks could sometimes occur on group commits with a high number of concurrent updates, as well as when one client held a lock from a commit while another client imposed a lock while rotating the binary log.
- Replication: When semisynchronous replication was enabled, the automatic dropping on the master of an event created using ON COMPLETION NOT PRESERVE caused the master to fail.
- Replication: Setting a SET column to NULL inside a stored procedure caused replication to fail.
- Replication: The binary log contents got corrupted sometimes, because the function MYSQL_BIN_LOG::write_cache always thought it had reached the end-of-cache when the function my_b_fill() reported a '0,' while that could also mean an error had occurred. This fix makes sure that whenever my_b_fill() returns a '0,' an error check is performed on info->error.
- Replication: PURGE BINARY LOGS by design does not remove binary log files that are in use or active, but did not provide any notice when this occurred. Now, when log files are not removed under such conditions, a warning is issued; this warning includes information about the file or files were not removed when the statement was issued.
- Replication: When replicating to a BLACKHOLE table using the binary logging format, updates and deletes cannot be applied and so are skipped. Now a warning is generated for this whenever it occurs. Note:
- binlog_format=STATEMENT is recommended when replicating to tables that use the BLACKHOLE storage engine.
- Removing a server RPM package did not shut down the existing server if it was running.
- Overhead for setting PROCESSLIST_STATE values in the Performance Schema THREADS table has been reduced.
- The Windows authentication plugin failed to free a context buffer for each connection.
- The DBUG_PRINT() macro unnecessarily evaluated arguments when debugging was not enabled.
- When index condition pushdown was used on a descending range scan and the first range interval did not contain any qualifying records, the result of the range scan could be empty even if other range intervals contained qualifying records.
- The server could attempt a filesort operation for a zero-size sort length, causing it to exit.
- my_load_defaults() was modified to accommodate some problems under compilation with gcc 4.7.2 that could cause a client crash during option processing.
- Opening a cursor on a SELECT within a stored procedure could cause a segmentation fault.
- SET PASSWORD treated user@'%' and user@'' as referring to the same mysql.user table row.
- Geometry methods that worked with WKB data performed insufficient input data validation, which could cause Valgrind errors or a server exit.
- Some INFORMATION_SCHEMA queries that used ORDER BY did not use a filesort optimization as they did in MySQL 5.5. (Bug #16423536)
- Performance Schema parameter autosizing at startup did not take into account later autosizing changes to other startup parameters on which the Performance Schema parameters depended.
- The WKB reader for spatial operations could fail and cause a server exit.
- Optimizer heuristics inappropriately preferred range access over ref access in cases when the ref access referred to a column of a table earlier in the join seqence.
- Manually-created accounts (using INSERT) with a malformed password effectively had no password.
- Several scripts in the sql-bench directory that were supposed to be executable did not have the executable access bit set.
- For debug builds, DBUG_EXPLAIN resulted in a buffer overflow when the debug system variable value was more than 255 characters.
- Within an XA transaction in ACTIVE state, statements causing an implicit commit could result in metadata locks being released too early.
- Installing Debian packages on Ubuntu 12.10 succeeded using dpkg, but not with Software Center 5.4.1.4.
- For debug builds, with an XA transaction in IDLE or PREPARED status, execution of a query with the query cache enabled could cause a server exit.
- thread_pool_high_priority_connection could not be set at server startup.
- Re-execution of a stored procedure could cause a server exit in Item_field::fix_outer_field.
- A GROUP_CONCAT() invocation containing subquery having an outer reference caused the server to exit.
- With secure_auth enabled, a user with a password that used the pre-4.1 (old) hashing could not update it to use the 4.1 (new) hashing.
- For debug builds, GROUP_CONCAT(... ORDER BY) within an ORDER BY clause could cause a server exit.
- The validate_password plugin did not always enforce appropriate constraints against assigning empty passwords.
- For debug builds, the server could exit for queries involving a nested subquery, a subquery tranformed into a semi-join and using a view.
- The range optimizer could set up incorrect ranges for queries that used XOR operations.
- mysql_secure_installation could not connect to the server if the account used had an expired password. It invoked mysql noninteractively, resulting in that program failing to connect. Now mysql supports a --connect-expired-password option that indicates to the server that it can handle sandbox mode for expired-password accounts even if invoked noninteractively, and mysql_secure_installation invokes mysql with this option.
- If loose index scan was used on a query that used MIN(), a segmentation fault could occur.
- If multiple statements were sent in a single request, the audit log plugin logged only the last one. Now it logs each statement separately.
- For debug builds, an assertion was incorrectly raised for queries executed using eq_ref access and filesort.
- An outer join between a regular table and a derived table that is implicitly groups could cause a server exit.
- A prepared statement that used GROUP_CONCAT() and an ORDER BY clause that named multiple columns could cause the server to exit.
- Creating a FEDERATED table without specifying a connection string caused a server exit. ORDER BY MATCH ... AGAINST could cause a server exit.
- Client programs from MySQL 5.6.4 and up could confuse older servers during the connection process by using newer protocol features not understood by older servers.
- When a partition is missing, code in ha_innodb.cc would retry 10 times and sleep for a microsecond each time while holding LOCK_open. The retry logic for partitioned tables was introduced as a fix for Bug#33349 but did not include a test case to validate it. This fix removes the retry logic for partitioned tables. If the problem reported in Bug#33349 reappears, a different solution will be explored.
- The mysql.server script exited with an error if the status command was executed with multiple servers running.
- Use of the VALUES() function in the VALUES() clause of an INSERT statement could result in Valgrind warnings or an unstable server, possibly leading to a server exit.
- In some cases, REVOKE could fail to revoke the GRANT OPTION privilege.
- The mysql client allocated but did not free a string after reading each line in interactive mode, resulting in a memory leak.
- Killing a connection while it was in the process of disconnecting could lead to an assertion being raised, Valgrind warnings, and general unstability.
- INSERT ... ON DUPLICATE KEY UPDATE on a view could cause a server exit. (Bug #14261010)
- Grouping by an outer BLOB column in a subquery caused a server exit.
- The server could exit due to improper handling of the error from an invalid comparison.
- The CMake check for unsigned time_t failed on all platforms.
- mysqladmin debug causes the server to write debug information to the error log. On systems that supported mallinfo(), the memory-status part of this output was incorrect in 64-bit environments when mysqld consumed more than 4GB memory.
- Now the server uses malloc_info() to obtain memory-status information. malloc_info() does not report the memory that the glibc malloc() implementation internally allocates using mmap(). However, it does provide the memory usage information in all the memory arenas.
- This bug fix also involves a change of output format. The server now writes memory information in XML format rather than as plain text.
- The mysql client incorrectly used latin1 for certain comparisons even if started with a multibyte default character set, resulting in a client crash.
- The url columns in the mysql datatbase help tables were too short to hold some of the URLs in the help content. These columns are now created as type TEXT to accommodate longer URLs.
- mysqld --help and mysqld --verbose --help performed unnecessary logging.
- InnoDB does not support full-text parser plugins, but failed to report an error if they were specified. Now an ER_INNODB_NO_FT_USES_PARSER error is returned.
- If Loose Index Scan was used to evaluate a query that compared an integer column to an integer specified as a quoted string (for example, col_name = '1'), the query could return incorrect results.
- IF() function evaluations could produce different results when executed in a prepared versus nonprepared statement.
- If a function such as AES_DECRYPT() that requires SSL support failed, the error could affect later calls to functions that require SSL support.
- In a MySQL server newer than MySQL 5.5 using a nonupgraded mysql.user table (for which mysql_upgrade had not been run), statements to set passwords caused a server exit due to a faulty check for the password_expired column.
- It is now possible to suppress installation of the mysql-test directory after compiling MySQL from source by invoking CMake with the INSTALL_MYSQLTESTDIR option explicitly set to empty:
- cmake . -DINSTALL_MYSQLTESTDIR=. Previously, attempts to do this resulted in an error.
- When only counting events but not timing them, Performance Schema would report MIN_TIMER_WAIT values as a large number instead of 0.
- Using range access with an index prefix could produce incorrect results.
- For debug builds, metadata locking for CREATE TABLE ... SELECT could raise an assertion.
- A new CMake option, WITH_EDITLINE, is provided to indicate whether to use the bundled or system libedit/editline library. The permitted values are bundled (the default) and system.
- WITH_EDITLINE replaces WITH_LIBEDIT, which has been removed.
- When specified in an option file, the plugin-dir client option was ignored.
- Indexes on derived tables that were used during the first invocation of a stored procedure were not used in subsequent invocations.
- For DELETE and UPDATE statements, EXPLAIN displayed NULL in the ref column for some cases where const is more appropriate.
- The optimizer could choose a poor execution plan for queries with ORDER BY ... LIMIT.
- FOUND_ROWS() could return an incorrect value if the preceding query used filesort

更新時間：2013-06-04
更新細節：

What's new in this version:

Bugs Fixed:
- Important Change; Replication: When the server was running with --binlog-ignore-db and SELECT DATABASE() returned NULL (that is, there was no currently selected database), statements using fully qualified table names in dbname.tblname format were not written to the binary log. This was because the lack of a currently selected database in such cases was treated as a match for any possible ignore option rather than for no such option; this meant that these statements were always ignored. Now, if there is no current database, a statement using fully qualified table names is always written to the binary log. 
- InnoDB: Valgrind testing returned memory leak errors which resulted from a regression . The dict_create_add_foreign_to_dictionary function would call pars_info_create but failed to call pars_info_free. 
- InnoDB: The fix for resulted in a linker error. 
- InnoDB: Crash recovery would fail with a !recv_no_log_write assertion when reading a page. 
- Replication: Using the --replicate-* options (see Replication Slave Options and Variables) could in some cases lead to a memory leak on the slave. 
- Replication: The binary log contents got corrupted sometimes, because the function MYSQL_BIN_LOG::write_cache always thought it had reached the end-of-cache when the function my_b_fill() reported a '0,' while that could also mean an error had occurred. This fix makes sure that whenever my_b_fill() returns a '0,' an error check is performed on info->error. 
- The WKB reader for spatial operations could fail and cause a server exit. 
- A GROUP_CONCAT() invocation containing subquery having an outer reference caused the server to exit. 
- For debug builds, GROUP_CONCAT(... ORDER BY) within an ORDER BY clause could cause a server exit. 
- If loose index scan was used on a query that used MIN(), a segmentation fault could occur. 
- A prepared statement that used GROUP_CONCAT() and an ORDER BY clause that named multiple columns could cause the server to exit. 
- ORDER BY MATCH ... AGAINST could cause a server exit. 
- When a partition is missing, code in ha_innodb.cc would retry 10 times and sleep for a microsecond each time while holding LOCK_open. The retry logic for partitioned tables was introduced as a fix but did not include a test case to validate it. This fix removes the retry logic for partitioned tables. If the problem reported reappears, a different solution will be explored. 
- The mysql.server script exited with an error if the status command was executed with multiple servers running. 
- When processing row-based-replication events in the old binary log format from prior to MySQL 5.1 GA builds, mysqlbinlog could result in out-of-bounds heap buffer reads and undefined behaviour. 
- The mysql client allocated but did not free a string after reading each line in interactive mode, resulting in a memory leak. 
- Grouping by an outer BLOB column in a subquery caused a server exit. 
- The url columns in the mysql datatbase help tables were too short to hold some of the URLs in the help content. For new installations, these columns are now created as type TEXT to accommodate longer URLs.
- For upgrades, mysql_upgrade does not update the columns. Modify them manually using these statements:
ALTER TABLE mysql.help_category MODIFY url TEXT NOT NULL;
ALTER TABLE mysql.help_topic MODIFY url TEXT NOT NULL;
- The test for stack overrun did not work for recent gcc versions and could lead to server exit. 
- IF() function evaluations could produce different results when executed in a prepared versus nonprepared statement.

更新時間：2013-04-20
更新細節：

What's new in this version:

Functionality Added or Changed:
- Replication: The functions GTID_SUBTRACT() and GTID_SUBSET() were formerly available in libmysqld only when it was built with replication support. Now these functions are always available when using this library, regardless of how it was built.
- MySQL no longer uses the default OpenSSL compression. (Bug #16235681)
- There is now a distinct error code (ER_MUST_CHANGE_PASSWORD_LOGIN) for the error sent by the server to a client authenticating with an expired password. (Bug #16102943)
- mysql_config_editor now supports --port and --socket options for specifying TCP/IP port number and Unix socket file name. (Bug #15851247)
- mysqlcheck has a new --skip-database option. The option value is the name of a database (case sensitive) for which checks should be skipped.
- mysql_upgrade uses this option to upgrade the system tables in the mysql database before tables in other databases: It upgrade the mysql database, then all databases except the mysql database. This avoids problems that can occur if user tables are upgraded before the system tables. (Bug #14697538)
- The only supported value for the innodb_mirrored_log_groups system variable is 1, so this variable is now deprecated. Setting it to 1 at startup results in a warning. Setting it to a value other than 1 at startup results in an error and the server exits. This variable will be removed in a future release.

Bugs Fixed:
- Performance; InnoDB: Switching the MySQL table used by the InnoDB memcached interface (using the @@ notation), was made more efficient, by reading cached information about the cache policy to use for each table. This optimization lets you frequently switch between tables during a session that uses the memcached interface, without incurring I/O overhead from examining table metadata each time. (Bug #16206654)
- Performance; InnoDB: Performance was improved for operations on tables with many rows that were deleted but not yet purged. The speedup applies mainly to workloads that perform bulk deletes, or updates to the primary key columns, and where the system is busy enough to experience purge lag. (Bug #16138582, Bug #68069)
- Performance; InnoDB: The DROP TABLE statement for a table using compression could be slower than necessary, causing a stall for several seconds. MySQL was unnecessarily decompressing pages in the buffer pool related to the table as part of the DROP operation. (Bug #16067973)
- Performance; InnoDB: The I/O routines used when the AIO subsystem were made more efficient, to merge consecutive I/O requests into a single operation. This fix solves a performance issue introduced during the 5.6 development cycle. (Bug #16043841, Bug #67973)
- Incompatible Change; Partitioning: Changes in the KEY partitioning hashing functions used with numeric, date and time, ENUM, and SET columns in MySQL 5.5 makes tables using partitioning or subpartitioning by KEY on any of the affected column types and created on a MySQL 5.5 or later server incompatible with a MySQL 5.1 server. This is because the partition IDs as calculated by a MySQL 5.5 or later server almost certainly differ from those calculated by a MySQL 5.1 server for the same table definition and data as a result of the changes in these functions.
- The principal changes in the KEY partitioning implementation in MySQL 5.5 resulting in this issue were as follows: 1. The hash function used for numeric and date and time columns changed from binary to character-based. 2. The base used for hashing of ENUM and SET columns changed from latin1 ci characters to binary.
The fix involves adding the capability in MySQL 5.5 and later to choose which type of hashing to use for KEY partitioning, which is implemented with a new ALGORITHM extension to the PARTITION BY KEY option for CREATE TABLE and ALTER TABLE. Specifying PARTITION BY KEY ALGORITHM=1 ([columns]) causes the server to use the hashing functions as implemented in MySQL 5.1; using ALGORITHM=2 causes the server to use the hashing functions from MySQL 5.5 and later. ALGORITHM=2 is the default. Using the appropriate value for ALGORITHM, you can perform any of the following tasks:
- Create KEY partitioned tables in MySQL 5.5 and later that are compatible with MySQL 5.1, using CREATE TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
- Downgrade KEY partitioned tables that were created in MySQL 5.5 or later to become compatible with MySQL 5.1, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
- Upgrade KEY partitioned tables originally created in MySQL 5.1 to use hashing as in MySQL 5.5 and later, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=2 (...).
- Important: After such tables are upgraded, they cannot be used any longer with MySQL 5.1 unless they are first downgraded again using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...) on a MySQL server supporting this option.
- This syntax is not backward compatible, and causes errors in older versions of the MySQL server. When generating CREATE TABLE ... PARTITION BY KEY statements, mysqldump brackets any occurrence of ALGORITHM=1 or ALGORITHM=2 in conditional comments such that it is ignored by a MySQL server whose version is not at least 5.5.31. An additional consideration for upgrades is that MySQL 5.6 servers prior to MySQL 5.6.11 do not ignore the ALGORITHM option in such statements when generated by a MySQL 5.5 server, due to the that the conditional comments refer to version 5.5.31; in this case, you must edit the dump manually and remove or comment out the option wherever it occurs before attempting to load it into a MySQL 5.6.10 or earlier MySQL 5.6 server. This is not an issue for dumps generated by MySQL 5.6.11 or later version of mysqldump, where the version used in such comments is 5.6.11. For more information, see ALTER TABLE Partition Operations.
- As part of this fix, a spurious assertion by InnoDB that a deleted row had previously been read, causing the server to assert on delete of a row that the row was in the wrong partition, was also removed. (Bug #14521864, Bug #66462, Bug #16093958, Bug #16274455)

Important Change; Replication: Executing a statement that performs an implicit commit but whose changes are not logged when gtid_next is set to any value other than AUTOMATIC is not permitted. Now in such cases, the statement fails with an error. This includes the statements in the following list:
- CHANGE MASTER TO
- START SLAVE
- STOP SLAVE
- REPAIR TABLE
- OPTIMIZE TABLE
- ANALYZE TABLE
- CHECK TABLE
- CREATE SERVER
- ALTER SERVER
- DROP SERVER
- CACHE INDEX
- LOAD INDEX INTO CACHE
- FLUSH
- RESET

- Important Change; Replication: The version number reported by mysqlbinlog --version has been increased to 3.4. (Bug #15894381, Bug #67643)
- Important Note; Replication: It was possible to replicate from a table to a same-named view using statement-based logging, while using row-based logging instead led to a failure on the slave. Now the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table. This is true regardless of the binary logging format in use. (Bug #11752707, Bug #43975)
- InnoDB: When ADD PRIMARY KEY columns are reordered in an ALTER TABLE statement (for example: ALTER TABLE t1 ADD PRIMARY KEY(a,b), CHANGE a a INT AFTER b), the log apply for UPDATE operations would fail to find rows. (Bug #16586355)
- InnoDB: ALTER TABLE operations on InnoDB tables that added a PRIMARY KEY using a column prefix could produce an incorrect result. (Bug #16544336)
- InnoDB: For ALTER TABLE operations on InnoDB tables that required a table-copying operation, other transactions on the table might fail during the copy. However, if such a transaction issued a partial rollback, the rollback was treated as a full rollback. (Bug #16544143)
- InnoDB: When parsing a delimited search string such as “abc-def” in a full-text search, InnoDB now uses the same word delimiters as MyISAM. (Bug #16419661)
- InnoDB: This fix improves code readability by addressing naming inconsistencies for InnoDB PERFORMANCE_SCHEMA key declarations. (Bug #16414044)
- InnoDB: This fix disables a condition for extra splitting of clustered index leaf pages, on compressed tables. Extra page splitting was only done to reserve space for future updates, so that future page splits could be avoided. (Bug #16401801)
- InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR column (or prefix) was empty, index page compression could fail. (Bug #16400920)
- InnoDB: Status values in the INNODB_FT_CONFIG table would not update. The INNODB_FT_CONFIG is intended for internal configuration and should not be used for statistical information purposes. To avoid confusion, column values that are intended for internal use have been removed from the INNODB_FT_CONFIG table. This fix also removes the INNODB_FT_INSERTED table and other internal full text search-related tables that were unintentionally exposed. (Bug #16409494)
- InnoDB: With innodb_api_enable_mdl=OFF, an ALTER TABLE operation on an InnoDB table that required a table copy could cause a server exit. (Bug #16287411)
- InnoDB: Improper testing of compatibility between the referencing and referenced during ALTER TABLE ... ADD FOREIGN key could cause a server exit. (Bug #16330036)
- InnoDB: Rollback did not include changes made to temporary tables by read-only transactions. (Bug #16310467)
- InnoDB: The InnoDB page-splitting algorithm could recurse excessivly. (Bug #16345265)
- InnoDB: For debug builds, InnoDB status exporting was subject to a race condition that could cause a server exit. (Bug #16292043)
- InnoDB: When using ALTER TABLE to set an AUTO_INCREMENT column value to a user-specified value, InnoDB would set the AUTO_INCREMENT value to the user-specified value even when the AUTO_INCREMENT value is greater than the user-specified value. This fix ensures that the AUTO_INCREMENT value is set to the maximum of the user-specified value and MAX(auto_increment_column)+1, which is the expected behaviour. (Bug #16310273)
- InnoDB: Importing a tablespace with the configuration file present would not import the data file. This problem would occur when all pages are not flushed from the buffer pool after a table is altered using the copy and rename approach. This fix ensures that all pages are flushed from the buffer pool when a table is altered using the copy and rename approach. (Bug #16318052)
- InnoDB: RENAME TABLE would result in a hang due to a MySQL mutex acquisition deadlock. (Bug #16305265)
- InnoDB: Internal read operations could be misclassified as synchronous when they were actually asynchronous. When the I/O requests returned sooner than expected, threads could be scheduled inefficiently. This issue mainly affected read-ahead requests, and thus had relatively little impact on I/O performed by user queries. (Bug #16249505, Bug #68197)
- InnoDB: The lock_validate function, which is only present in debug builds, acquired and released mutexes to avoid hogging them. This behavior introduced a window wherein changes to the hash table could occur while code traversed the same set of data. This fix updates lock_validate logic to collect all records for which locks must be validated, releases mutexes, and runs a loop to validate record locks. (Bug #16235056)
- InnoDB: ALTER TABLE functions would perform a check to see if InnoDB is in read-only mode (srv_read_only_mode=true). If InnoDB was in read-only mode, the check would return a successful status and do nothing else. This fix replaces srv_read_only_mode check conditions with debug assertions. (Bug #16227539)
- InnoDB: An improper call to abort() by InnoDB could result in a server exit. (Bug #16263506)
- InnoDB: When the InnoDB buffer pool is almost filled with 4KB compressed pages, inserting into 16KB compact tables would cause 8KB pages_free to increase, which could potentially slow or stall inserts. (Bug #16223169)
- InnoDB: An assertion failure would occur in heap->magic_n == MEM_BLOCK_MAGIC_N due to a race condition that appeared when row_merge_read_clustered_index() returned an error. (Bug #16275237)
- InnoDB: This fix removes an unnecessary debug assertion related to page_hash locks which only affects debug builds. The debug assertion is no longer valid and should have been removed when hash_lock array was introduced in MySQL 5.6. (Bug #16263167)
- InnoDB: The InnoDB memcached plugin could encounter a serious error under a heavy load, such as produced by benchmark runs. (Bug #16182660, Bug #68096)
- InnoDB: If the MySQL server halted at a precise moment when a purge operation was being applied from the change buffer, the operation could be incorrectly performed again during the next restart. A workaround was to set the configuration option innodb_change_buffering=changes, to turn off change buffering for purge operations. (Bug #16183892, Bug #14636528)
- InnoDB: When InnoDB locking code was revised, a call to register lock waits was inadvertently removed. This fix adds the call back to the InnoDB locking code. (Bug #16208201)
- InnoDB: A direct call to the trx_start_if_not_started_xa_low() function would cause a debug assertion. (Bug #16178995)
- InnoDB: In the case of LOCK WAIT for an insert in a foreign key table, InnoDB could report a false dictionary-changed error and cause the insert to fail rather than being retried. (Bug #16174255)
- InnoDB: In some cases, deadlock detection did not work, resulting in sessions hanging waiting for a lock-wait timeout. (Bug #16169638)
- InnoDB: An in-place ALTER TABLE on an InnoDB table could fail to delete the statistics for the old primary key from the mysql.innodb_index_stats table. (Bug #16170451)
- InnoDB: This fix updates InnoDB code in ha_innodb.cc and handler0alter.cc to use TABLE::key_info instead of both TABLE::key_info and TABLE_SHARE::key_info. (Bug #16215361)
- InnoDB: Arithmetic underflow during page compression for CREATE TABLE on an InnoDB table could cause a server exit. (Bug #16089381)
- InnoDB: For debug builds, online ALTER TABLE operations for InnoDB tables could cause a server exit during table rebuilding. (Bug #16063835)
- InnoDB: In some cases, the InnoDB purge coordinator did not use all available purge threads, resulting in suboptimal purge activity. (Bug #16037372)
- InnoDB: On systems that cannot handle unaligned memory access, depending on the stack frame alignment, a SIGBUS error could occur during startup. This issue was observed on Solaris 64-bit systems. (Bug #16021177)
- InnoDB: ALTER TABLE for InnoDB tables was not fully atomic. (Bug #15989081)
- InnoDB: When innodb_mirrored_log_groups was set to a value other than the default 1, the MySQL server encountered a serious error during startup while loading the InnoDB memcached plugin. In earlier releases, the server would refuse to start (but not display an error) when this setting was changed. This fix cleans up the error handling for unsupported values of this configuration option. (Bug #15907954, Bug #67670)
InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation. The error could be accompanied by Valgrind warnings, and by this assertion message:
- Assertion `! is_set()' failed.
- mysqld got signal 6 ;
- InnoDB: The INNODB_SYNC_ARRAY_SIZE variable was incorrectly allowed to be configured at runtime. As documented, INNODB_SYNC_ARRAY_SIZE must be configured when the MySQL instance is starting up, and cannot be changed afterward. This fix changes INNODB_SYNC_ARRAY_SIZE to a non-dynamic variable, as intended. (Bug #14629979)
- InnoDB: The server could exit during an attempt by InnoDB to reorganize or compress a compressed secondary index page. (Bug #14606334)
- InnoDB: A RENAME TABLE statement could stall for several minutes before timing out. This issue could occurred for a table using compression, with change buffering enabled. (Bug #14556349)
- InnoDB: A DML operation performed while a RENAME TABLE operation waits for pending I/O operations on the tablespace to complete would result in a deadlock. (Bug #14556349)
InnoDB: If the server was started with the skip-innodb option, or InnoDB otherwise failed to start, query any of these Information Schema tables would cause a severe error:
- INNODB_BUFFER_PAGE
- INNODB_BUFFER_PAGE_LRU
- INNODB_BUFFER_POOL_STATS

- InnoDB: Online DDL had a restriction that prevented renaming a column and adding a foreign key involving that column in a single ALTER TABLE statement. Now, this combination of operations is allowed in a single statement. (Bug #14105491)
- InnoDB: When printing out long semaphore wait diagnostics, sync_array_cell_print() ran into a segmentation violation (SEGV) caused by a race condition. This fix addresses the race condition by allowing the cell to be freed while it is being printed. (Bug #13997024)
- InnoDB: The value of the innodb_version variable was not updated consistently for all server releases for the InnoDB Plugin in MySQL 5.1, and the integrated InnoDB component in MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server development cycles are fully integrated and synchronized, now the value returned by the innodb_version variable is the same as for the version variable. (Bug #13463493, Bug #63435)
- InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced by the fix for Bug#14704286. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state. (Bug #68051, Bug #16088883)
- InnoDB: On startup, InnoDB reported a message on 64-bit Linux and 64-bit Windows systems stating that the CPU does not support crc32 instructions. On Windows, InnoDB does not use crc32 instructions even if supported by the CPU. This fix revises the wording of the message and implements a check for availability of crc32 instructions. (Bug #68035, Bug #16075806)
- InnoDB: The length of internally generated foreign key names was not checked. If internally generated foreign key names were over the 64 character limit, this resulted in invalid DDL from SHOW CREATE TABLE. This fix checks the length of internally generated foreign key names and reports an error message if the limit is exceeded. (Bug #44541, Bug #11753153)
- InnoDB: This fix removes left-over prototype code for srv_parse_log_group_home_dirs, and related header comments. (Bug #68133, Bug #16198764)
- InnoDB: Attempting to replace the default InnoDB FTS stopword list by creating an InnoDB table with the same structure as INFORMATION_SCHEMA.innodb_ft_default_stopword would result in an error. SHOW CREATE TABLE revealed that the new InnoDB table was created with CHARSET=utf8. The InnoDB FTS stopword table validity check only supported latin1. This fix extends the validity check for all supported character sets. (Bug #68450, Bug #16373868)
- Partitioning: ALGORITHM = INPLACE, which was disallowed in MySQL 5.6.10 for DDL statements operating on partitioned tables, can once again be used with such statements. (Bug #16216513)
- Partitioning: A query on a table partitioned by range and using TO_DAYS() as a partitioing function always included the first partition of the table when pruning. This happened regardless of the range employed in the BETWEEN clause of such a query. (Bug #15843818, Bug #49754)
- Partitioning: Execution of ALTER TABLE ... DROP PARTITION against a view caused the server to crash, rather than fail with an error as expected. (Bug #14653504)
- Partitioning: A query result was not sorted if both DISTINCT and ORDER BY were used and the underlying table was partitioned. (Bug #14058167)
- Partitioning: Inserting any number of rows into an ARCHIVE table that used more than 1000 partitions and then attempting to drop the table caused the MySQL Server to fail. (Bug #13819630, Bug #64580)
- Replication: When using GTIDs and binary log auto-positioning, the master had to scan all binary logs whenever the slave reconnected (due to reasons such as I/O thread failure or a change of master) before it could send any events to slave. Now, the master starts from the oldest binary log that contains any GTID not found on the slave. (Bug #16340322, Bug #68386)
- Replication: When the server version of the master was greater than or equal to 10, replication to a slave having a lower server version failed. (Bug #16237051, Bug #68187)
- Replication: When replicating to a MySQL 5.6 master to an older slave, Error 1193 (ER_UNKNOWN_SYSTEM_VARIABLE) was logged with a message such as Unknown system variable 'SERVER_UUID' on master, maybe it is a *VERY OLD MASTER*. This message has been improved to include more information, similar to this one: Unknown system variable 'SERVER_UUID' on master. A probable cause is that the variable is not supported on the master (version: 5.5.31), even though it is on the slave (version: 5.6.11). (Bug #16216404, Bug #68164)
- Replication: A zero-length name for a user variable (such as @``) was incorrectly considered to be a sign of data or network corruption when reading from the binary log. (Bug #16200555, Bug #68135)
- Replication: When MTS is on and transactions are being applied, the slave coordinator would hang when encountering a checksum error on a transaction event. This was due to a deadlock situation in which the coordinator assumed a normal stop while a worker waited for the coordinator to dispatch more events. For debug builds, the problem appeared as an assertion failure, which was due to the coordinator not setting thd->is_error() when encountering an error. (Bug #16210351)
- Replication: mysqlbinlog can connect to a remote server and read its binary logs. In MySQL 5.6 and later, this tool can also wait for the server to generate and send additional events, in practice behaving like a slave connecting to a master. In cases where the server sent a heartbeat, mysqlbinlog was unable to handle it properly. As a consequence, mysqlbinlog failed at this point, without reading any more events from the server. To fix this problem, mysqlbinlog now ignores any binary log events of type HEARTBEAT_LOG_EVENT that it receives. (Bug #16104206)
- Replication: STOP SLAVE could cause a deadlock when issued concurrently with a statement such as SHOW STATUS that retrieved the values for one or more of the status variables Slave_retried_transactions, Slave_heartbeat_period, Slave_received_heartbeats, Slave_last_heartbeat, or Slave_running. (Bug #16088188, Bug #67545)
- Replication: Using the --replicate-* options (see Replication Slave Options and Variables) could in some cases lead to a memory leak on the slave. (Bug #16056813, Bug #67983)
- Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave. (Bug #16084594, Bug #68045)
- References: This bug is a regression of Bug #14548159, Bug #66550.
- Replication: The session-level value for gtid_next was incorrectly reset on the slave for all rollbacks, which meant that GTIDs could be lost for multi-statement transactions, causing the slave to stop with an ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error. Now this is done only when a complete transaction is being rolled back, or when autocommit is enabled. (Bug #16084206)
- Replication: In order to provision or to restore a server using GTIDs, it is possible to set gtid_purged to a given GTID set listing the transactions that were imported. This operation requires that the global gtid_executed and gtid_purged server system variables are empty. (This is done in order to avoid the possibility of overriding server-generated GTIDs.)
- The error message GTID_PURGED can only be set when GTID_EXECUTED is empty that was raised when this requirement was not met could be confusing or misleading because it did not specify the scope of the affected variables. To prevent this from happening, error messages that refer to variables relating to GTIDs now specify the scope of any such variables when they do so. (Bug #16084426, Bug #68038)
- Replication: In certain cases, the dump thread could send a heartbeat out of synchronisation with format description events. One of the effects of this issue what that, after provisioning a new server from a backup data directory and setting --gtid-mode=ON and enabling autopositioning (see CHANGE MASTER TO Syntax), replication failed to start, with the error Read invalid event from master.... The same problem could also cause GTID-based replication to fail due to skipped events following a unplanned shutdown of the master. (Bug #16051857)
- Replication: In some cases, when the slave could not recognize the server version of the master, this could cause the slave to fail. (Bug #16056365)
Replication: Table IDs used in replication were defined as type ulong on the master and uint on the slave. In addition, the maximum value for table IDs in binary log events is 6 bytes (281474976710655). This combination of factors led to the following issues:
- Data could be lost on the slave when a table was assigned an ID greater than uint.
- Table IDs greater than 281474976710655 were written to the binary log as 281474976710655.
- This led to a stopped slave when the slave encountered two tables having the same table ID.
- To fix these problems, IDs are now defined by both master and slave as type ulonglong but constrained to a range of 0 to 281474976710655, restarting from 0 when it exceeds this value. (Bug #14801955, Bug #67352)
- Replication: Internal objects used for relay log information were only partially deleted before freeing their memory. (Bug #14677824)
- Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place. (Bug #13545447, Bug #67929)
- Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead. (Bug #11753923, Bug #45449)
- Microsoft Windows: In Shared Memory mode, the MySQL Server could crash when receiving requests from multiple threads. (Bug #13934876)
- Failure to handle a full-text search wildcard properly could cause the server to exit. (Bug #16446108)
- InnoDB now reports row and table locks to the thread pool plugin. Deadlocks within a thread group could occur otherwise. (Bug #16448639)
- SHOW ENGINE PERFORMANCE_SCHEMA STATUS could report incorrect memory-allocation values when the correct values exceeded 4GB. (Bug #16414644)
- Performance Schema statement tokenization overhead was reduced. (Bug #16382260)
- A long database name in a GRANT statement could cause the server to exit. (Bug #16372927)
- The server could exit if a prepared statement attempted to create a table using the name of an existing view while an SQL handler was opened. (Bug #16385711)
- For debug builds, checking of password constraints could raise an assertion for statements that updated passwords. (Bug #16289303)
- The BUILD-CMAKE file in MySQL distributions was updated with the correct URL for CMake information. (Bug #16328024)
- A Valgrind failure could occur if a CREATE USER statement was logged to the general query log and the old_passwords system variable was set to 2. (Bug #16300620)
- The optimizer's attempt to remove redundant subquery clauses raised an assertion when executing a prepared statement with a subquery in the ON clause of a join in a subquery. (Bug #16318585)
- References: This bug is a regression of Bug #15875919.
- Very small join_buffer_size values could cause an assertion to be raised. (Bug #16328373)
- Some aggregate queries attempted to allocate excessive memory. (Bug #16343992)
- Incorrect results were returned if a query contained a subquery in an IN clause which contained an XOR operation in the WHERE clause. (Bug #16311231)
- For debug builds, an assertion could be raised if a statement failed with autocommit enabled just before an XA START statement was issued. (Bug #16341673)
- Conversion of numeric values to BIT could yield unexpected results. (Bug #16271540)
- Certain legal HAVING clauses were rejected as invalid. (Bug #16221433)
- Fixed warnings when compiling with XCode 4.6. Fixed warnings when compiling when the _XOPEN_SOURCE or isoctal macro was already defined in the environment. (Bug #16265300, Bug #60911, Bug #12407384)
- Queries using range predicates that were evaluated using the LooseScan semi-join strategy could return duplicate rows. (Bug #16221623)
- References: This bug is a regression of Bug #14728469.
- For upgrade operations, RPM packages produced unnecessary errors about being unable to access .err files. (Bug #16235828)
- In the range optimizer, an index merge failure could cause a server exit. (Bug #16241773)
A full-text query using Boolean mode could return zero results in some cases where the search term was a quoted phrase:
If the quoted phrase was preceded by a + sign. For example, this combination of a Boolean + operator and a phrase would return zero results:
- where match(content) against('+"required term due to plus sign"' in boolean mode)
If the quoted phrase contained any stopwords. For example, the stopword "the" inside the phrase caused the query to return zero results:
- where match(content) against('"stopword inside the phrase"' in boolean mode)
- For debug builds, the server could exit due to incorrect calculation of applicable indexes for a join that involved const tables. (Bug #16165832)
- A bug in range optimization sometimes led to incorrect condition calculation for index merge union. This could lead to missing rows. (Bug #16164031, Bug #68194, Bug #16229746)
- The Performance Schema could return incorrect values for the PROCESSLIST_INFO column of the threads table. (Bug #16215165)
- Invocation of the range optimizer for a NULL select caused the server to exit. (Bug #16192219)
- mysql_config --libs displayed incorrect output. (Bug #16200717)
- For a CREATE TABLE (... col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ...) ... SELECT statement for which the SELECT did not provide a value for the TIMESTAMP column, that column was set to '0000-00-00 00:00:00', not the current timestamp. (Bug #16163936)
- yaSSL did not perform proper padding checks, but instead examined only the last byte of plaintext and used it to determine how many bytes to remove. (Bug #16218104)
- Using GROUP BY WITH ROLLUP in a prepared statement could cause the server to exit. (Bug #16163596)
- If, in a SELECT, the HAVING clause contained a function call which itself contained an alias to a selected expression, the server could sometimes exit. (Bug #16165981)
- Setting the slave_rows_search_algorithms system variable to an inappropriate value could cause the server to exit. (Bug #16074161)
- Directory name manipulation could result in stack overflow on Mac OS X and Windows. (Bug #16066243)
- With statement-based binary logging, dropping a TEMPORARY InnoDB table could cause a segmentation fault. (Bug #16076275)
- For debug builds, if the server was started with binary logging disabled, executing SHOW RELAYLOG EVENTS from within a stored procedure raised an assertion. (Bug #16043173)
- The query parser leaked memory for some syntax errors. (Bug #16040022)
- With the thread pool plugin enabled, large numbers of connections could lead to a Valgrind panic or failure of clients to be able to connect. (Bug #16088658, Bug #16196591)
- The server executed EXPLAIN FORMAT=JSON for some malformed queries improperly. (Bug #16078557)
- Performance Schema instrumentation was missing for slave worker threads. (Bug #16083949)
The initial test database contained a dummy.bak file that prevented DROP DATABASE from working. This file is no longer included. Also, a db.opt file is now included that contains these lines:
- default-character-set=latin1
- default-collation=latin1_swedish_ci
- Setting a system variable to DEFAULT could cause the server to exit. (Bug #16044655)
- SET PASSWORD and GRANT ... IDENTIFIED BY have no effect on the password of a user who is authenticated using an authentication plugin that accesses passwords stored externally to the mysql.user table. But attempts to change the password of such a user produced no warning, leading to the impression that the password had been changed when it was not. Now MySQL issues an ER_SET_PASSWORD_AUTH_PLUGIN warning to indicate that the attempt was ignored. (Bug #16072004)
- For debug builds, creating an InnoDB table in strict SQL mode that violated the maximum key length limit caused the server to exit. (Bug #16035659)
- Issuing a PREPARE statement using certain combinations of stored functions and user variables caused the server to exit. (Bug #16056537)
- Joins of exactly 32 tables and containing a HAVING clause returned an empty result. (Bug #15972635)
- A mysys library string-formatting routine could mishandle width specifiers. (Bug #15960005)
- The --character-set-server option could set connection character set system variables to values such as ucs2 that are not permitted. (Bug #15985752)
- During shutdown, the server could attempt to lock an uninitialized mutex. (Bug #16016493)
- The --default-authentication-plugin option permitted invalid plugin values, and did not always set the old_passwords system variable to a value appropriate for the named plugin. (Bug #16014394)
- Under some circumstances, mysql --secure-auth permitted passwords to be sent to the server using the old (pre-4.1) hashing format. (Bug #15977433)
- With index condition pushdown enabled, queries for which the pushed-down condition contained no columns in the used index could be slow. (Bug #15896009)
- Table creation operations added entries to the Performance Schema file_instances table, but these were not always removed for table drop operations. (Bug #15927620)
- In special cases, the optimizer did not consider indexes that were applicable to query processing, resulting in potentially suboptimal execution and incorrect EXPLAIN output. (Bug #15849135, Bug #16094171)
- A query with an EXISTS/IN/ALL/ANY subquery with an ORDER BY clause ordering by an outer column of type BLOB that is not in the select list caused an assertion to fire. (Bug #15875919)
- Creating an InnoDB table with a FULLTEXT index could encounter a serious error if the table name contained nonalphanumeric characters. (Bug #14835178, Bug #16036699)
- Enabling the query cache during high client contention could cause the server to exit. (Bug #14727815)
- The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug #14627287)
- The optimizer could return incorrect results after transforming an IN subquery with aggregate functions to an EXISTS subquery. (Bug #14586710)
- When a client program loses the connection to the MySQL server or if the server begins a shutdown after the client has executed mysql_stmt_prepare(), the next mysql_stmt_prepare() returns an error (as expected) but subsequent mysql_stmt_execute() calls crash the client. (Bug #14553380)
- Previously, if multiple --login-path options were given, mysql_config_editor ignored all but the last one. Now multiple --login-path options result in an error. (Bug #14551712)
- SET PASSWORD for anonymous users did not work correctly. (Bug #14561102)
- SHOW COLUMNS on a view defined as a UNION of Geometry columns could cause the server to exit. (Bug #14362617)
- The sha256_password_private_key_path and sha256_password_public_key_path system variables indicate key files for the sha256_password authentication plugin, but the server failed to properly check whether the key files were valid. Now in the event that either key file is invalid, the server logs an error and exits. (Bug #14360513)
- SET var_name = VALUES(col_name) could cause the server to exit. This syntax is now prohibited because in SET context there is no column name and the statement returns ER_BAD_FIELD_ERROR. (Bug #14211565)
- The COM_CHANGE_USER command in the client/server protocol did not properly use the character set number in the command packet, leading to incorrect character set conversion of other values in the packet. (Bug #14163155)
- Invoking the FORMAT() function with a locale and a very large number could cause the server to exit. (Bug #14040155)
- yaSSL rejected some valid server SSL certificates. (Bug #13777928)
Certain plugin-related conditions can make a user account unusable:
- The account requires an authentication plugin that is not loaded.
- The account requires the sha256_password authentication plugin but the server was started with neither SSL nor RSA enabled as required by this plugin.
- The server now checks those conditions by default and produces warnings for unusable accounts. This checking slows down server initialization and FLUSH PRIVILEGES, so it is made optional by means of the new validate_user_plugins system variable. This variable is enabled by default, but if you do not require the additional checking, you can disable it at startup to avoid the performance decrement. (Bug #13010061, Bug #14506305)
- Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. (Bug #12347040)
- The obsolete linuxthreads.txt and glibc-2.2.5.patch files in the Docs directory of MySQL distributions have been removed. (Bug #11766326)
- mysql_install_db did not escape '_' in the host name for statements written to the grant tables. (Bug #11746817)
- mysqld_safe used the nonportable -e test construct. (Bug #67976, Bug #16046140)
- An out-of-memory condition could occur while handling an out-of-memory error, leading to recursion in error handling. (Bug #49514, Bug #11757464)
- The optimizer used loose index scan for some queries for which this access method is inapplicable. (Bug #42785, Bug #11751794)
- If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations” error. (Bug #65382, Bug #14117025)
- The REPLACE() function produced incorrect results when a user variable was supplied as an argument and the operation was performed on multiple rows. (Bug #49271, Bug #11757250)
- UNION type conversion could incorrectly turn unsigned values into signed values. (Bug #49003, Bug #11757005)
- UNION ALL on BLOB columns could produce incorrect results. (Bug #50136, Bug #11758009)
- View access in low memory conditions could raise a debugging assertion. (Bug #39307, Bug #11749556)
- Queries with many values in a IN() clause were slow due to inclusion of debugging code in non-debugging builds. (Bug #68046, Bug #16078212)
- Setting max_connections to a value less than the current number of open connections caused the server to exit. (Bug #44100, Bug #11752803)
- Some table I/O performed by the server when calling a storage engine were missing from the statistics collected by the Performance Schema. (Bug #68180, Bug #16222630)
- For debug builds, some queries with SELECT ... FROM DUAL nested subqueries raised an assertion. (Bug #60305, Bug #11827369)
- Nonspatial indexes only support exact-match lookups for spatial columns, but the optimizer incorrectly used range access in some cases, leading to incorrect results. (Bug #67889, Bug #15993693)
- If mysql is built with the bundled libedit library, the library is built as static code, to avoid linking to a different dynamic version at runtime. Dynamic linking could result in use of a different, incompatible version and a segmentation fault. (Bug #68231, Bug #16296509)
- The --log-slow-admin-statements and --log-slow-slave-statements command options now are exposed at runtime as the log_slow_admin_statements and log_slow_slave_statements system variables. Their values can be examined using SHOW VARIABLES. The variables are dynamic, so their values can can be set at runtime. (The options were actually replaced by the system variables, but as system variables can be set at server startup, no option functionality is lost.) (Bug #59860, Bug #11766693)
- For arguments with fractional seconds greater than six decimals, SEC_TO_TIME() truncated, rather than rounding as it should have. (Bug #68061, Bug #16093024)
- MySQL failed to build if configured with WITH_LIBWRAP enabled. (Bug #67018, Bug #16342793)
- If the server was started without a --datadir option, SHOW VARIABLES could show an empty value for the datadir system variable. (Bug #60995, Bug #12546953)
- Configuring with -DWITH_SSL=/path/to/openssl resulted in link errors due to selection of the incorrect libcrypto. (Bug #68277, Bug #16284051)
- ALTER TABLE tbl_name ADD COLUMN col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP inserted 0000-00-00 00:00:00 rather than the current timestamp if the alteration was done in place rather than by making a table copy. (Bug #68040, Bug #16076089)
- If the server was started with --skip-grant-tables, ALTER USER ... PASSWORD EXPIRE caused the server to exit. (Bug #68300, Bug #16295905)
- CMake did not check whether the system zlib had certain functions required for MySQL, resulting in build errors. Now it checks and falls back to the bundled zlib if the functions are missing. (Bug #65856, Bug #14300733)
- mysql_install_db did not work in Solaris 10 sparse root zones. (Bug #68117, Bug #16197860)
- For EXPLAIN DELETE and EXPLAIN UPDATE the possible_keys column listed all indexes, not just the applicable indexes. (Bug #67830, Bug #15972078)
- The Perl version of mysql_install_db mishandled some error messages. (Bug #68118, Bug #16197542)
- Handling of SQL_CALC_FOUND_ROWS in combination with ORDER BY and LIMIT could lead to incorrect results for FOUND_ROWS(). (Bug #68458, Bug #16383173)
- Adding an ORDER BY clause following an IN subquery could cause duplicate rows to be returned. (Bug #68330, Bug #16308085)
- If INET6_NTOA() or INET6_ATON() returned NULL for a row in a result set, following rows also returned NULL. (Bug #68454, Bug #16373973)
- A statement with an aggregated, nongrouped outer query and an aggregated, nongrouped subquery in the SELECT list could return incorrect results. (Bug #68372, Bug #16325175)
- With explicit_defaults_for_timestamp enabled, inserting NULL into a TIMESTAMP NOT NULL column now produces an error (as it already did for other NOT NULL data types), instead of inserting the current timestamp. (Bug #68472, Bug #16394472)

更新時間：2013-04-20
更新細節：

What's new in this version:

Functionality Added or Changed:
- Replication: The functions GTID_SUBTRACT() and GTID_SUBSET() were formerly available in libmysqld only when it was built with replication support. Now these functions are always available when using this library, regardless of how it was built.
- MySQL no longer uses the default OpenSSL compression. (Bug #16235681)
- There is now a distinct error code (ER_MUST_CHANGE_PASSWORD_LOGIN) for the error sent by the server to a client authenticating with an expired password. (Bug #16102943)
- mysql_config_editor now supports --port and --socket options for specifying TCP/IP port number and Unix socket file name. (Bug #15851247)
- mysqlcheck has a new --skip-database option. The option value is the name of a database (case sensitive) for which checks should be skipped.
- mysql_upgrade uses this option to upgrade the system tables in the mysql database before tables in other databases: It upgrade the mysql database, then all databases except the mysql database. This avoids problems that can occur if user tables are upgraded before the system tables. (Bug #14697538)
- The only supported value for the innodb_mirrored_log_groups system variable is 1, so this variable is now deprecated. Setting it to 1 at startup results in a warning. Setting it to a value other than 1 at startup results in an error and the server exits. This variable will be removed in a future release.

Bugs Fixed:
- Performance; InnoDB: Switching the MySQL table used by the InnoDB memcached interface (using the @@ notation), was made more efficient, by reading cached information about the cache policy to use for each table. This optimization lets you frequently switch between tables during a session that uses the memcached interface, without incurring I/O overhead from examining table metadata each time. (Bug #16206654)
- Performance; InnoDB: Performance was improved for operations on tables with many rows that were deleted but not yet purged. The speedup applies mainly to workloads that perform bulk deletes, or updates to the primary key columns, and where the system is busy enough to experience purge lag. (Bug #16138582, Bug #68069)
- Performance; InnoDB: The DROP TABLE statement for a table using compression could be slower than necessary, causing a stall for several seconds. MySQL was unnecessarily decompressing pages in the buffer pool related to the table as part of the DROP operation. (Bug #16067973)
- Performance; InnoDB: The I/O routines used when the AIO subsystem were made more efficient, to merge consecutive I/O requests into a single operation. This fix solves a performance issue introduced during the 5.6 development cycle. (Bug #16043841, Bug #67973)
- Incompatible Change; Partitioning: Changes in the KEY partitioning hashing functions used with numeric, date and time, ENUM, and SET columns in MySQL 5.5 makes tables using partitioning or subpartitioning by KEY on any of the affected column types and created on a MySQL 5.5 or later server incompatible with a MySQL 5.1 server. This is because the partition IDs as calculated by a MySQL 5.5 or later server almost certainly differ from those calculated by a MySQL 5.1 server for the same table definition and data as a result of the changes in these functions.
- The principal changes in the KEY partitioning implementation in MySQL 5.5 resulting in this issue were as follows: 1. The hash function used for numeric and date and time columns changed from binary to character-based. 2. The base used for hashing of ENUM and SET columns changed from latin1 ci characters to binary.
The fix involves adding the capability in MySQL 5.5 and later to choose which type of hashing to use for KEY partitioning, which is implemented with a new ALGORITHM extension to the PARTITION BY KEY option for CREATE TABLE and ALTER TABLE. Specifying PARTITION BY KEY ALGORITHM=1 ([columns]) causes the server to use the hashing functions as implemented in MySQL 5.1; using ALGORITHM=2 causes the server to use the hashing functions from MySQL 5.5 and later. ALGORITHM=2 is the default. Using the appropriate value for ALGORITHM, you can perform any of the following tasks:
- Create KEY partitioned tables in MySQL 5.5 and later that are compatible with MySQL 5.1, using CREATE TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
- Downgrade KEY partitioned tables that were created in MySQL 5.5 or later to become compatible with MySQL 5.1, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
- Upgrade KEY partitioned tables originally created in MySQL 5.1 to use hashing as in MySQL 5.5 and later, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=2 (...).
- Important: After such tables are upgraded, they cannot be used any longer with MySQL 5.1 unless they are first downgraded again using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...) on a MySQL server supporting this option.
- This syntax is not backward compatible, and causes errors in older versions of the MySQL server. When generating CREATE TABLE ... PARTITION BY KEY statements, mysqldump brackets any occurrence of ALGORITHM=1 or ALGORITHM=2 in conditional comments such that it is ignored by a MySQL server whose version is not at least 5.5.31. An additional consideration for upgrades is that MySQL 5.6 servers prior to MySQL 5.6.11 do not ignore the ALGORITHM option in such statements when generated by a MySQL 5.5 server, due to the that the conditional comments refer to version 5.5.31; in this case, you must edit the dump manually and remove or comment out the option wherever it occurs before attempting to load it into a MySQL 5.6.10 or earlier MySQL 5.6 server. This is not an issue for dumps generated by MySQL 5.6.11 or later version of mysqldump, where the version used in such comments is 5.6.11. For more information, see ALTER TABLE Partition Operations.
- As part of this fix, a spurious assertion by InnoDB that a deleted row had previously been read, causing the server to assert on delete of a row that the row was in the wrong partition, was also removed. (Bug #14521864, Bug #66462, Bug #16093958, Bug #16274455)

Important Change; Replication: Executing a statement that performs an implicit commit but whose changes are not logged when gtid_next is set to any value other than AUTOMATIC is not permitted. Now in such cases, the statement fails with an error. This includes the statements in the following list:
- CHANGE MASTER TO
- START SLAVE
- STOP SLAVE
- REPAIR TABLE
- OPTIMIZE TABLE
- ANALYZE TABLE
- CHECK TABLE
- CREATE SERVER
- ALTER SERVER
- DROP SERVER
- CACHE INDEX
- LOAD INDEX INTO CACHE
- FLUSH
- RESET

- Important Change; Replication: The version number reported by mysqlbinlog --version has been increased to 3.4. (Bug #15894381, Bug #67643)
- Important Note; Replication: It was possible to replicate from a table to a same-named view using statement-based logging, while using row-based logging instead led to a failure on the slave. Now the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table. This is true regardless of the binary logging format in use. (Bug #11752707, Bug #43975)
- InnoDB: When ADD PRIMARY KEY columns are reordered in an ALTER TABLE statement (for example: ALTER TABLE t1 ADD PRIMARY KEY(a,b), CHANGE a a INT AFTER b), the log apply for UPDATE operations would fail to find rows. (Bug #16586355)
- InnoDB: ALTER TABLE operations on InnoDB tables that added a PRIMARY KEY using a column prefix could produce an incorrect result. (Bug #16544336)
- InnoDB: For ALTER TABLE operations on InnoDB tables that required a table-copying operation, other transactions on the table might fail during the copy. However, if such a transaction issued a partial rollback, the rollback was treated as a full rollback. (Bug #16544143)
- InnoDB: When parsing a delimited search string such as “abc-def” in a full-text search, InnoDB now uses the same word delimiters as MyISAM. (Bug #16419661)
- InnoDB: This fix improves code readability by addressing naming inconsistencies for InnoDB PERFORMANCE_SCHEMA key declarations. (Bug #16414044)
- InnoDB: This fix disables a condition for extra splitting of clustered index leaf pages, on compressed tables. Extra page splitting was only done to reserve space for future updates, so that future page splits could be avoided. (Bug #16401801)
- InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR column (or prefix) was empty, index page compression could fail. (Bug #16400920)
- InnoDB: Status values in the INNODB_FT_CONFIG table would not update. The INNODB_FT_CONFIG is intended for internal configuration and should not be used for statistical information purposes. To avoid confusion, column values that are intended for internal use have been removed from the INNODB_FT_CONFIG table. This fix also removes the INNODB_FT_INSERTED table and other internal full text search-related tables that were unintentionally exposed. (Bug #16409494)
- InnoDB: With innodb_api_enable_mdl=OFF, an ALTER TABLE operation on an InnoDB table that required a table copy could cause a server exit. (Bug #16287411)
- InnoDB: Improper testing of compatibility between the referencing and referenced during ALTER TABLE ... ADD FOREIGN key could cause a server exit. (Bug #16330036)
- InnoDB: Rollback did not include changes made to temporary tables by read-only transactions. (Bug #16310467)
- InnoDB: The InnoDB page-splitting algorithm could recurse excessivly. (Bug #16345265)
- InnoDB: For debug builds, InnoDB status exporting was subject to a race condition that could cause a server exit. (Bug #16292043)
- InnoDB: When using ALTER TABLE to set an AUTO_INCREMENT column value to a user-specified value, InnoDB would set the AUTO_INCREMENT value to the user-specified value even when the AUTO_INCREMENT value is greater than the user-specified value. This fix ensures that the AUTO_INCREMENT value is set to the maximum of the user-specified value and MAX(auto_increment_column)+1, which is the expected behaviour. (Bug #16310273)
- InnoDB: Importing a tablespace with the configuration file present would not import the data file. This problem would occur when all pages are not flushed from the buffer pool after a table is altered using the copy and rename approach. This fix ensures that all pages are flushed from the buffer pool when a table is altered using the copy and rename approach. (Bug #16318052)
- InnoDB: RENAME TABLE would result in a hang due to a MySQL mutex acquisition deadlock. (Bug #16305265)
- InnoDB: Internal read operations could be misclassified as synchronous when they were actually asynchronous. When the I/O requests returned sooner than expected, threads could be scheduled inefficiently. This issue mainly affected read-ahead requests, and thus had relatively little impact on I/O performed by user queries. (Bug #16249505, Bug #68197)
- InnoDB: The lock_validate function, which is only present in debug builds, acquired and released mutexes to avoid hogging them. This behavior introduced a window wherein changes to the hash table could occur while code traversed the same set of data. This fix updates lock_validate logic to collect all records for which locks must be validated, releases mutexes, and runs a loop to validate record locks. (Bug #16235056)
- InnoDB: ALTER TABLE functions would perform a check to see if InnoDB is in read-only mode (srv_read_only_mode=true). If InnoDB was in read-only mode, the check would return a successful status and do nothing else. This fix replaces srv_read_only_mode check conditions with debug assertions. (Bug #16227539)
- InnoDB: An improper call to abort() by InnoDB could result in a server exit. (Bug #16263506)
- InnoDB: When the InnoDB buffer pool is almost filled with 4KB compressed pages, inserting into 16KB compact tables would cause 8KB pages_free to increase, which could potentially slow or stall inserts. (Bug #16223169)
- InnoDB: An assertion failure would occur in heap->magic_n == MEM_BLOCK_MAGIC_N due to a race condition that appeared when row_merge_read_clustered_index() returned an error. (Bug #16275237)
- InnoDB: This fix removes an unnecessary debug assertion related to page_hash locks which only affects debug builds. The debug assertion is no longer valid and should have been removed when hash_lock array was introduced in MySQL 5.6. (Bug #16263167)
- InnoDB: The InnoDB memcached plugin could encounter a serious error under a heavy load, such as produced by benchmark runs. (Bug #16182660, Bug #68096)
- InnoDB: If the MySQL server halted at a precise moment when a purge operation was being applied from the change buffer, the operation could be incorrectly performed again during the next restart. A workaround was to set the configuration option innodb_change_buffering=changes, to turn off change buffering for purge operations. (Bug #16183892, Bug #14636528)
- InnoDB: When InnoDB locking code was revised, a call to register lock waits was inadvertently removed. This fix adds the call back to the InnoDB locking code. (Bug #16208201)
- InnoDB: A direct call to the trx_start_if_not_started_xa_low() function would cause a debug assertion. (Bug #16178995)
- InnoDB: In the case of LOCK WAIT for an insert in a foreign key table, InnoDB could report a false dictionary-changed error and cause the insert to fail rather than being retried. (Bug #16174255)
- InnoDB: In some cases, deadlock detection did not work, resulting in sessions hanging waiting for a lock-wait timeout. (Bug #16169638)
- InnoDB: An in-place ALTER TABLE on an InnoDB table could fail to delete the statistics for the old primary key from the mysql.innodb_index_stats table. (Bug #16170451)
- InnoDB: This fix updates InnoDB code in ha_innodb.cc and handler0alter.cc to use TABLE::key_info instead of both TABLE::key_info and TABLE_SHARE::key_info. (Bug #16215361)
- InnoDB: Arithmetic underflow during page compression for CREATE TABLE on an InnoDB table could cause a server exit. (Bug #16089381)
- InnoDB: For debug builds, online ALTER TABLE operations for InnoDB tables could cause a server exit during table rebuilding. (Bug #16063835)
- InnoDB: In some cases, the InnoDB purge coordinator did not use all available purge threads, resulting in suboptimal purge activity. (Bug #16037372)
- InnoDB: On systems that cannot handle unaligned memory access, depending on the stack frame alignment, a SIGBUS error could occur during startup. This issue was observed on Solaris 64-bit systems. (Bug #16021177)
- InnoDB: ALTER TABLE for InnoDB tables was not fully atomic. (Bug #15989081)
- InnoDB: When innodb_mirrored_log_groups was set to a value other than the default 1, the MySQL server encountered a serious error during startup while loading the InnoDB memcached plugin. In earlier releases, the server would refuse to start (but not display an error) when this setting was changed. This fix cleans up the error handling for unsupported values of this configuration option. (Bug #15907954, Bug #67670)
InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation. The error could be accompanied by Valgrind warnings, and by this assertion message:
- Assertion `! is_set()' failed.
- mysqld got signal 6 ;
- InnoDB: The INNODB_SYNC_ARRAY_SIZE variable was incorrectly allowed to be configured at runtime. As documented, INNODB_SYNC_ARRAY_SIZE must be configured when the MySQL instance is starting up, and cannot be changed afterward. This fix changes INNODB_SYNC_ARRAY_SIZE to a non-dynamic variable, as intended. (Bug #14629979)
- InnoDB: The server could exit during an attempt by InnoDB to reorganize or compress a compressed secondary index page. (Bug #14606334)
- InnoDB: A RENAME TABLE statement could stall for several minutes before timing out. This issue could occurred for a table using compression, with change buffering enabled. (Bug #14556349)
- InnoDB: A DML operation performed while a RENAME TABLE operation waits for pending I/O operations on the tablespace to complete would result in a deadlock. (Bug #14556349)
InnoDB: If the server was started with the skip-innodb option, or InnoDB otherwise failed to start, query any of these Information Schema tables would cause a severe error:
- INNODB_BUFFER_PAGE
- INNODB_BUFFER_PAGE_LRU
- INNODB_BUFFER_POOL_STATS

- InnoDB: Online DDL had a restriction that prevented renaming a column and adding a foreign key involving that column in a single ALTER TABLE statement. Now, this combination of operations is allowed in a single statement. (Bug #14105491)
- InnoDB: When printing out long semaphore wait diagnostics, sync_array_cell_print() ran into a segmentation violation (SEGV) caused by a race condition. This fix addresses the race condition by allowing the cell to be freed while it is being printed. (Bug #13997024)
- InnoDB: The value of the innodb_version variable was not updated consistently for all server releases for the InnoDB Plugin in MySQL 5.1, and the integrated InnoDB component in MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server development cycles are fully integrated and synchronized, now the value returned by the innodb_version variable is the same as for the version variable. (Bug #13463493, Bug #63435)
- InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced by the fix for Bug#14704286. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state. (Bug #68051, Bug #16088883)
- InnoDB: On startup, InnoDB reported a message on 64-bit Linux and 64-bit Windows systems stating that the CPU does not support crc32 instructions. On Windows, InnoDB does not use crc32 instructions even if supported by the CPU. This fix revises the wording of the message and implements a check for availability of crc32 instructions. (Bug #68035, Bug #16075806)
- InnoDB: The length of internally generated foreign key names was not checked. If internally generated foreign key names were over the 64 character limit, this resulted in invalid DDL from SHOW CREATE TABLE. This fix checks the length of internally generated foreign key names and reports an error message if the limit is exceeded. (Bug #44541, Bug #11753153)
- InnoDB: This fix removes left-over prototype code for srv_parse_log_group_home_dirs, and related header comments. (Bug #68133, Bug #16198764)
- InnoDB: Attempting to replace the default InnoDB FTS stopword list by creating an InnoDB table with the same structure as INFORMATION_SCHEMA.innodb_ft_default_stopword would result in an error. SHOW CREATE TABLE revealed that the new InnoDB table was created with CHARSET=utf8. The InnoDB FTS stopword table validity check only supported latin1. This fix extends the validity check for all supported character sets. (Bug #68450, Bug #16373868)
- Partitioning: ALGORITHM = INPLACE, which was disallowed in MySQL 5.6.10 for DDL statements operating on partitioned tables, can once again be used with such statements. (Bug #16216513)
- Partitioning: A query on a table partitioned by range and using TO_DAYS() as a partitioing function always included the first partition of the table when pruning. This happened regardless of the range employed in the BETWEEN clause of such a query. (Bug #15843818, Bug #49754)
- Partitioning: Execution of ALTER TABLE ... DROP PARTITION against a view caused the server to crash, rather than fail with an error as expected. (Bug #14653504)
- Partitioning: A query result was not sorted if both DISTINCT and ORDER BY were used and the underlying table was partitioned. (Bug #14058167)
- Partitioning: Inserting any number of rows into an ARCHIVE table that used more than 1000 partitions and then attempting to drop the table caused the MySQL Server to fail. (Bug #13819630, Bug #64580)
- Replication: When using GTIDs and binary log auto-positioning, the master had to scan all binary logs whenever the slave reconnected (due to reasons such as I/O thread failure or a change of master) before it could send any events to slave. Now, the master starts from the oldest binary log that contains any GTID not found on the slave. (Bug #16340322, Bug #68386)
- Replication: When the server version of the master was greater than or equal to 10, replication to a slave having a lower server version failed. (Bug #16237051, Bug #68187)
- Replication: When replicating to a MySQL 5.6 master to an older slave, Error 1193 (ER_UNKNOWN_SYSTEM_VARIABLE) was logged with a message such as Unknown system variable 'SERVER_UUID' on master, maybe it is a *VERY OLD MASTER*. This message has been improved to include more information, similar to this one: Unknown system variable 'SERVER_UUID' on master. A probable cause is that the variable is not supported on the master (version: 5.5.31), even though it is on the slave (version: 5.6.11). (Bug #16216404, Bug #68164)
- Replication: A zero-length name for a user variable (such as @``) was incorrectly considered to be a sign of data or network corruption when reading from the binary log. (Bug #16200555, Bug #68135)
- Replication: When MTS is on and transactions are being applied, the slave coordinator would hang when encountering a checksum error on a transaction event. This was due to a deadlock situation in which the coordinator assumed a normal stop while a worker waited for the coordinator to dispatch more events. For debug builds, the problem appeared as an assertion failure, which was due to the coordinator not setting thd->is_error() when encountering an error. (Bug #16210351)
- Replication: mysqlbinlog can connect to a remote server and read its binary logs. In MySQL 5.6 and later, this tool can also wait for the server to generate and send additional events, in practice behaving like a slave connecting to a master. In cases where the server sent a heartbeat, mysqlbinlog was unable to handle it properly. As a consequence, mysqlbinlog failed at this point, without reading any more events from the server. To fix this problem, mysqlbinlog now ignores any binary log events of type HEARTBEAT_LOG_EVENT that it receives. (Bug #16104206)
- Replication: STOP SLAVE could cause a deadlock when issued concurrently with a statement such as SHOW STATUS that retrieved the values for one or more of the status variables Slave_retried_transactions, Slave_heartbeat_period, Slave_received_heartbeats, Slave_last_heartbeat, or Slave_running. (Bug #16088188, Bug #67545)
- Replication: Using the --replicate-* options (see Replication Slave Options and Variables) could in some cases lead to a memory leak on the slave. (Bug #16056813, Bug #67983)
- Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave. (Bug #16084594, Bug #68045)
- References: This bug is a regression of Bug #14548159, Bug #66550.
- Replication: The session-level value for gtid_next was incorrectly reset on the slave for all rollbacks, which meant that GTIDs could be lost for multi-statement transactions, causing the slave to stop with an ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error. Now this is done only when a complete transaction is being rolled back, or when autocommit is enabled. (Bug #16084206)
- Replication: In order to provision or to restore a server using GTIDs, it is possible to set gtid_purged to a given GTID set listing the transactions that were imported. This operation requires that the global gtid_executed and gtid_purged server system variables are empty. (This is done in order to avoid the possibility of overriding server-generated GTIDs.)
- The error message GTID_PURGED can only be set when GTID_EXECUTED is empty that was raised when this requirement was not met could be confusing or misleading because it did not specify the scope of the affected variables. To prevent this from happening, error messages that refer to variables relating to GTIDs now specify the scope of any such variables when they do so. (Bug #16084426, Bug #68038)
- Replication: In certain cases, the dump thread could send a heartbeat out of synchronisation with format description events. One of the effects of this issue what that, after provisioning a new server from a backup data directory and setting --gtid-mode=ON and enabling autopositioning (see CHANGE MASTER TO Syntax), replication failed to start, with the error Read invalid event from master.... The same problem could also cause GTID-based replication to fail due to skipped events following a unplanned shutdown of the master. (Bug #16051857)
- Replication: In some cases, when the slave could not recognize the server version of the master, this could cause the slave to fail. (Bug #16056365)
Replication: Table IDs used in replication were defined as type ulong on the master and uint on the slave. In addition, the maximum value for table IDs in binary log events is 6 bytes (281474976710655). This combination of factors led to the following issues:
- Data could be lost on the slave when a table was assigned an ID greater than uint.
- Table IDs greater than 281474976710655 were written to the binary log as 281474976710655.
- This led to a stopped slave when the slave encountered two tables having the same table ID.
- To fix these problems, IDs are now defined by both master and slave as type ulonglong but constrained to a range of 0 to 281474976710655, restarting from 0 when it exceeds this value. (Bug #14801955, Bug #67352)
- Replication: Internal objects used for relay log information were only partially deleted before freeing their memory. (Bug #14677824)
- Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place. (Bug #13545447, Bug #67929)
- Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead. (Bug #11753923, Bug #45449)
- Microsoft Windows: In Shared Memory mode, the MySQL Server could crash when receiving requests from multiple threads. (Bug #13934876)
- Failure to handle a full-text search wildcard properly could cause the server to exit. (Bug #16446108)
- InnoDB now reports row and table locks to the thread pool plugin. Deadlocks within a thread group could occur otherwise. (Bug #16448639)
- SHOW ENGINE PERFORMANCE_SCHEMA STATUS could report incorrect memory-allocation values when the correct values exceeded 4GB. (Bug #16414644)
- Performance Schema statement tokenization overhead was reduced. (Bug #16382260)
- A long database name in a GRANT statement could cause the server to exit. (Bug #16372927)
- The server could exit if a prepared statement attempted to create a table using the name of an existing view while an SQL handler was opened. (Bug #16385711)
- For debug builds, checking of password constraints could raise an assertion for statements that updated passwords. (Bug #16289303)
- The BUILD-CMAKE file in MySQL distributions was updated with the correct URL for CMake information. (Bug #16328024)
- A Valgrind failure could occur if a CREATE USER statement was logged to the general query log and the old_passwords system variable was set to 2. (Bug #16300620)
- The optimizer's attempt to remove redundant subquery clauses raised an assertion when executing a prepared statement with a subquery in the ON clause of a join in a subquery. (Bug #16318585)
- References: This bug is a regression of Bug #15875919.
- Very small join_buffer_size values could cause an assertion to be raised. (Bug #16328373)
- Some aggregate queries attempted to allocate excessive memory. (Bug #16343992)
- Incorrect results were returned if a query contained a subquery in an IN clause which contained an XOR operation in the WHERE clause. (Bug #16311231)
- For debug builds, an assertion could be raised if a statement failed with autocommit enabled just before an XA START statement was issued. (Bug #16341673)
- Conversion of numeric values to BIT could yield unexpected results. (Bug #16271540)
- Certain legal HAVING clauses were rejected as invalid. (Bug #16221433)
- Fixed warnings when compiling with XCode 4.6. Fixed warnings when compiling when the _XOPEN_SOURCE or isoctal macro was already defined in the environment. (Bug #16265300, Bug #60911, Bug #12407384)
- Queries using range predicates that were evaluated using the LooseScan semi-join strategy could return duplicate rows. (Bug #16221623)
- References: This bug is a regression of Bug #14728469.
- For upgrade operations, RPM packages produced unnecessary errors about being unable to access .err files. (Bug #16235828)
- In the range optimizer, an index merge failure could cause a server exit. (Bug #16241773)
A full-text query using Boolean mode could return zero results in some cases where the search term was a quoted phrase:
If the quoted phrase was preceded by a + sign. For example, this combination of a Boolean + operator and a phrase would return zero results:
- where match(content) against('+"required term due to plus sign"' in boolean mode)
If the quoted phrase contained any stopwords. For example, the stopword "the" inside the phrase caused the query to return zero results:
- where match(content) against('"stopword inside the phrase"' in boolean mode)
- For debug builds, the server could exit due to incorrect calculation of applicable indexes for a join that involved const tables. (Bug #16165832)
- A bug in range optimization sometimes led to incorrect condition calculation for index merge union. This could lead to missing rows. (Bug #16164031, Bug #68194, Bug #16229746)
- The Performance Schema could return incorrect values for the PROCESSLIST_INFO column of the threads table. (Bug #16215165)
- Invocation of the range optimizer for a NULL select caused the server to exit. (Bug #16192219)
- mysql_config --libs displayed incorrect output. (Bug #16200717)
- For a CREATE TABLE (... col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ...) ... SELECT statement for which the SELECT did not provide a value for the TIMESTAMP column, that column was set to '0000-00-00 00:00:00', not the current timestamp. (Bug #16163936)
- yaSSL did not perform proper padding checks, but instead examined only the last byte of plaintext and used it to determine how many bytes to remove. (Bug #16218104)
- Using GROUP BY WITH ROLLUP in a prepared statement could cause the server to exit. (Bug #16163596)
- If, in a SELECT, the HAVING clause contained a function call which itself contained an alias to a selected expression, the server could sometimes exit. (Bug #16165981)
- Setting the slave_rows_search_algorithms system variable to an inappropriate value could cause the server to exit. (Bug #16074161)
- Directory name manipulation could result in stack overflow on Mac OS X and Windows. (Bug #16066243)
- With statement-based binary logging, dropping a TEMPORARY InnoDB table could cause a segmentation fault. (Bug #16076275)
- For debug builds, if the server was started with binary logging disabled, executing SHOW RELAYLOG EVENTS from within a stored procedure raised an assertion. (Bug #16043173)
- The query parser leaked memory for some syntax errors. (Bug #16040022)
- With the thread pool plugin enabled, large numbers of connections could lead to a Valgrind panic or failure of clients to be able to connect. (Bug #16088658, Bug #16196591)
- The server executed EXPLAIN FORMAT=JSON for some malformed queries improperly. (Bug #16078557)
- Performance Schema instrumentation was missing for slave worker threads. (Bug #16083949)
The initial test database contained a dummy.bak file that prevented DROP DATABASE from working. This file is no longer included. Also, a db.opt file is now included that contains these lines:
- default-character-set=latin1
- default-collation=latin1_swedish_ci
- Setting a system variable to DEFAULT could cause the server to exit. (Bug #16044655)
- SET PASSWORD and GRANT ... IDENTIFIED BY have no effect on the password of a user who is authenticated using an authentication plugin that accesses passwords stored externally to the mysql.user table. But attempts to change the password of such a user produced no warning, leading to the impression that the password had been changed when it was not. Now MySQL issues an ER_SET_PASSWORD_AUTH_PLUGIN warning to indicate that the attempt was ignored. (Bug #16072004)
- For debug builds, creating an InnoDB table in strict SQL mode that violated the maximum key length limit caused the server to exit. (Bug #16035659)
- Issuing a PREPARE statement using certain combinations of stored functions and user variables caused the server to exit. (Bug #16056537)
- Joins of exactly 32 tables and containing a HAVING clause returned an empty result. (Bug #15972635)
- A mysys library string-formatting routine could mishandle width specifiers. (Bug #15960005)
- The --character-set-server option could set connection character set system variables to values such as ucs2 that are not permitted. (Bug #15985752)
- During shutdown, the server could attempt to lock an uninitialized mutex. (Bug #16016493)
- The --default-authentication-plugin option permitted invalid plugin values, and did not always set the old_passwords system variable to a value appropriate for the named plugin. (Bug #16014394)
- Under some circumstances, mysql --secure-auth permitted passwords to be sent to the server using the old (pre-4.1) hashing format. (Bug #15977433)
- With index condition pushdown enabled, queries for which the pushed-down condition contained no columns in the used index could be slow. (Bug #15896009)
- Table creation operations added entries to the Performance Schema file_instances table, but these were not always removed for table drop operations. (Bug #15927620)
- In special cases, the optimizer did not consider indexes that were applicable to query processing, resulting in potentially suboptimal execution and incorrect EXPLAIN output. (Bug #15849135, Bug #16094171)
- A query with an EXISTS/IN/ALL/ANY subquery with an ORDER BY clause ordering by an outer column of type BLOB that is not in the select list caused an assertion to fire. (Bug #15875919)
- Creating an InnoDB table with a FULLTEXT index could encounter a serious error if the table name contained nonalphanumeric characters. (Bug #14835178, Bug #16036699)
- Enabling the query cache during high client contention could cause the server to exit. (Bug #14727815)
- The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug #14627287)
- The optimizer could return incorrect results after transforming an IN subquery with aggregate functions to an EXISTS subquery. (Bug #14586710)
- When a client program loses the connection to the MySQL server or if the server begins a shutdown after the client has executed mysql_stmt_prepare(), the next mysql_stmt_prepare() returns an error (as expected) but subsequent mysql_stmt_execute() calls crash the client. (Bug #14553380)
- Previously, if multiple --login-path options were given, mysql_config_editor ignored all but the last one. Now multiple --login-path options result in an error. (Bug #14551712)
- SET PASSWORD for anonymous users did not work correctly. (Bug #14561102)
- SHOW COLUMNS on a view defined as a UNION of Geometry columns could cause the server to exit. (Bug #14362617)
- The sha256_password_private_key_path and sha256_password_public_key_path system variables indicate key files for the sha256_password authentication plugin, but the server failed to properly check whether the key files were valid. Now in the event that either key file is invalid, the server logs an error and exits. (Bug #14360513)
- SET var_name = VALUES(col_name) could cause the server to exit. This syntax is now prohibited because in SET context there is no column name and the statement returns ER_BAD_FIELD_ERROR. (Bug #14211565)
- The COM_CHANGE_USER command in the client/server protocol did not properly use the character set number in the command packet, leading to incorrect character set conversion of other values in the packet. (Bug #14163155)
- Invoking the FORMAT() function with a locale and a very large number could cause the server to exit. (Bug #14040155)
- yaSSL rejected some valid server SSL certificates. (Bug #13777928)
Certain plugin-related conditions can make a user account unusable:
- The account requires an authentication plugin that is not loaded.
- The account requires the sha256_password authentication plugin but the server was started with neither SSL nor RSA enabled as required by this plugin.
- The server now checks those conditions by default and produces warnings for unusable accounts. This checking slows down server initialization and FLUSH PRIVILEGES, so it is made optional by means of the new validate_user_plugins system variable. This variable is enabled by default, but if you do not require the additional checking, you can disable it at startup to avoid the performance decrement. (Bug #13010061, Bug #14506305)
- Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. (Bug #12347040)
- The obsolete linuxthreads.txt and glibc-2.2.5.patch files in the Docs directory of MySQL distributions have been removed. (Bug #11766326)
- mysql_install_db did not escape '_' in the host name for statements written to the grant tables. (Bug #11746817)
- mysqld_safe used the nonportable -e test construct. (Bug #67976, Bug #16046140)
- An out-of-memory condition could occur while handling an out-of-memory error, leading to recursion in error handling. (Bug #49514, Bug #11757464)
- The optimizer used loose index scan for some queries for which this access method is inapplicable. (Bug #42785, Bug #11751794)
- If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations” error. (Bug #65382, Bug #14117025)
- The REPLACE() function produced incorrect results when a user variable was supplied as an argument and the operation was performed on multiple rows. (Bug #49271, Bug #11757250)
- UNION type conversion could incorrectly turn unsigned values into signed values. (Bug #49003, Bug #11757005)
- UNION ALL on BLOB columns could produce incorrect results. (Bug #50136, Bug #11758009)
- View access in low memory conditions could raise a debugging assertion. (Bug #39307, Bug #11749556)
- Queries with many values in a IN() clause were slow due to inclusion of debugging code in non-debugging builds. (Bug #68046, Bug #16078212)
- Setting max_connections to a value less than the current number of open connections caused the server to exit. (Bug #44100, Bug #11752803)
- Some table I/O performed by the server when calling a storage engine were missing from the statistics collected by the Performance Schema. (Bug #68180, Bug #16222630)
- For debug builds, some queries with SELECT ... FROM DUAL nested subqueries raised an assertion. (Bug #60305, Bug #11827369)
- Nonspatial indexes only support exact-match lookups for spatial columns, but the optimizer incorrectly used range access in some cases, leading to incorrect results. (Bug #67889, Bug #15993693)
- If mysql is built with the bundled libedit library, the library is built as static code, to avoid linking to a different dynamic version at runtime. Dynamic linking could result in use of a different, incompatible version and a segmentation fault. (Bug #68231, Bug #16296509)
- The --log-slow-admin-statements and --log-slow-slave-statements command options now are exposed at runtime as the log_slow_admin_statements and log_slow_slave_statements system variables. Their values can be examined using SHOW VARIABLES. The variables are dynamic, so their values can can be set at runtime. (The options were actually replaced by the system variables, but as system variables can be set at server startup, no option functionality is lost.) (Bug #59860, Bug #11766693)
- For arguments with fractional seconds greater than six decimals, SEC_TO_TIME() truncated, rather than rounding as it should have. (Bug #68061, Bug #16093024)
- MySQL failed to build if configured with WITH_LIBWRAP enabled. (Bug #67018, Bug #16342793)
- If the server was started without a --datadir option, SHOW VARIABLES could show an empty value for the datadir system variable. (Bug #60995, Bug #12546953)
- Configuring with -DWITH_SSL=/path/to/openssl resulted in link errors due to selection of the incorrect libcrypto. (Bug #68277, Bug #16284051)
- ALTER TABLE tbl_name ADD COLUMN col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP inserted 0000-00-00 00:00:00 rather than the current timestamp if the alteration was done in place rather than by making a table copy. (Bug #68040, Bug #16076089)
- If the server was started with --skip-grant-tables, ALTER USER ... PASSWORD EXPIRE caused the server to exit. (Bug #68300, Bug #16295905)
- CMake did not check whether the system zlib had certain functions required for MySQL, resulting in build errors. Now it checks and falls back to the bundled zlib if the functions are missing. (Bug #65856, Bug #14300733)
- mysql_install_db did not work in Solaris 10 sparse root zones. (Bug #68117, Bug #16197860)
- For EXPLAIN DELETE and EXPLAIN UPDATE the possible_keys column listed all indexes, not just the applicable indexes. (Bug #67830, Bug #15972078)
- The Perl version of mysql_install_db mishandled some error messages. (Bug #68118, Bug #16197542)
- Handling of SQL_CALC_FOUND_ROWS in combination with ORDER BY and LIMIT could lead to incorrect results for FOUND_ROWS(). (Bug #68458, Bug #16383173)
- Adding an ORDER BY clause following an IN subquery could cause duplicate rows to be returned. (Bug #68330, Bug #16308085)
- If INET6_NTOA() or INET6_ATON() returned NULL for a row in a result set, following rows also returned NULL. (Bug #68454, Bug #16373973)
- A statement with an aggregated, nongrouped outer query and an aggregated, nongrouped subquery in the SELECT list could return incorrect results. (Bug #68372, Bug #16325175)
- With explicit_defaults_for_timestamp enabled, inserting NULL into a TIMESTAMP NOT NULL column now produces an error (as it already did for other NOT NULL data types), instead of inserting the current timestamp. (Bug #68472, Bug #16394472)

更新時間：2013-04-19
更新細節：

What's new in this version:

Functionality Added or Changed:
- MySQL no longer uses the default OpenSSL compression. 

Bugs Fixed:
- Performance; InnoDB: The DROP TABLE statement for a table using compression could be slower than necessary, causing a stall for several seconds. MySQL was unnecessarily decompressing pages in the buffer pool related to the table as part of the DROP operation. 
- Important Note; Replication: It was possible to replicate from a table to a same-named view using statement-based logging, while using row-based logging instead led to a failure on the slave. Now the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table. This is true regardless of the binary logging format in use. 
- InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR column (or prefix) was empty, index page compression could fail. 
- InnoDB: For debug builds, InnoDB status exporting was subject to a race condition that could cause a server exit. 
- InnoDB: Arithmetic underflow during page compression for CREATE TABLE on an InnoDB table could cause a server exit. 
- InnoDB: This fix makes MySQL more responsive to KILL QUERY statements when the query is accessing an InnoDB table. 
- InnoDB: When printing out long semaphore wait diagnostics, sync_array_cell_print() ran into a segmentation violation (SEGV) caused by a race condition. This fix addresses the race condition by allowing the cell to be freed while it is being printed. 
- InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state. 
- InnoDB: The length of internally generated foreign key names was not checked. If internally generated foreign key names were over the 64 character limit, this resulted in invalid DDL from SHOW CREATE TABLE. This fix checks the length of internally generated foreign key names and reports an error message if the limit is exceeded. 
- Partitioning: A query on a table partitioned by range and using TO_DAYS() as a partitioing function always included the first partition of the table when pruning. This happened regardless of the range employed in the BETWEEN clause of such a query. 
- Replication: A zero-length name for a user variable (such as @``) was incorrectly considered to be a sign of data or network corruption when reading from the binary log. 
- Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave. 
- Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place. 
- A long database name in a GRANT statement could cause the server to exit. 
- Incorrect results were returned if a query contained a subquery in an IN clause which contained an XOR operation in the WHERE clause. 
- Invocation of the range optimizer for a NULL select caused the server to exit. 
- yaSSL did not perform proper padding checks, but instead examined only the last byte of plaintext and used it to determine how many bytes to remove. 
- SHOW COLUMNS on a view defined as a UNION of Geometry columns could cause the server to exit. 
- A LIKE pattern with too many '%' wildcards could cause a segmentation fault. 
- SET var_name = VALUES(col_name) could cause the server to exit. This syntax is now prohibited because in SET context there is no column name and the statement returns ER_BAD_FIELD_ERROR. 
- The COM_CHANGE_USER command in the client/server protocol did not properly use the character set number in - Subqueries with OUTER JOIN could return incorrect results if the subquery referred to a column from another SELECT. 
- Field_geom::reset() failed to reset its base Field_blob. The range optimizer used the uninitialized field during optimization and execution, causing the server to exit. 
- mysql_install_db did not escape '_' in the host name for statements written to the grant tables. 
- PARTITION BY KEY on a utf32 ENUM column raised a debugging assertion. 
- The optimizer used loose index scan for some queries for which this access method is inapplicable.
- If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations” error. 
- The REPLACE() function produced incorrect results when a user variable was supplied as an argument and the operation was performed on multiple rows. 
- UNION ALL on BLOB columns could produce incorrect results. 
- View access in low memory conditions could raise a debugging assertion. 
- Setting max_connections to a value less than the current number of open connections caused the server to exit. 
- Incorrect metadata could be produced for columns returned from some views. 
- For debug builds, some queries with SELECT ... FROM DUAL nested subqueries raised an assertion. 
- Adjusted MySQL configuration to account for change in Automake 1.12 that produced sql_yacc.hh rather than sql_yacc.h as expected by sql/Makefile.am.

更新時間：2013-02-05
更新細節：

What's new in this version:

Bugs Fixed:
- InnoDB; Performance: Some data structures related to undo logging could be initialized unnecessarily during a query, although they were only needed under specific conditions. 
- InnoDB; Performance: 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. 
- InnoDB; Performance: Immediately after a table was created, queries against it would not use loose index scans. The issue went away following an ALTER TABLE on the table. The fix improves the accuracy of the index statistics gathered when the table is first created, and prevents the query plan from being changed by the ALTER TABLE statement. 
- InnoDB; Partitioning: Previously, when attempting to optimize one or more partitions of a partitioned table that used a storage engine that does not support partition-level OPTIMIZE, such as InnoDB, MySQL reported Table does not support optimize, doing recreate + analyze instead, then re-created the entire table, but did not actually analyze it. Now in such cases, the warning message is, Table does not support optimize on partitions. All partitions will be rebuilt and analyzed. In addition, the entire table is analyzed after first being rebuilt. 
- InnoDB: The status variable Innodb_buffer_pool_read_ahead_evicted could show an inaccurate value, higher than expected, because some pages in the buffer pool were incorrectly considered as being brought in by read-ahead requests. 
- InnoDB: Creating an index on a CHAR column could fail for a table with a character set with varying length, such as UTF-8, if the table was created with the ROW_FORMAT=REDUNDANT clause. 
- InnoDB: If the server crashed at a precise moment during an ALTER TABLE operation that rebuilt the clustered index for an InnoDB table, the original table could be inaccessible afterward. An example of such an operation is ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original table if the server halts during this operation. You might still need to rename the .ibd file manually to restore the original table contents: in MySQL 5.6 and higher, rename from #sql-ib$new_table_id.ibd to table_name.ibd within the database directory; prior to MySQL 5.6, the temporary file to rename is table_name#1 or #2. 
- InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation. The error could be accompanied by Valgrind warnings, and by this assertion message: Assertion `! is_set()' failed. mysqld got signal 6 ; 
- InnoDB: During shutdown, with the innodb_purge_threads configuration option set greater than 1, the server could halt prematurely with this error: mysqld got signal 11 A workaround was to increase innodb_log_file_size and set innodb_purge_threads=1. The fix was backported to MySQL 5.5 and 5.1, although those versions do not have the innodb_purge_threads configuration option so the error was unlikely to occur. 
- InnoDB: The value of the innodb_version variable was not updated consistently for all server releases for the InnoDB Plugin in MySQL 5.1, and the integrated InnoDB component in MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server development cycles are fully integrated and synchronized, now the value returned by the innodb_version variable is the same as for the version variable. 
- Partitioning: When used with a table having multiple columns in its primary key, but partitioned by KEY using a column that was not part of the primary key as the partitioning column, a query using an aggregate function and DISTINCT such as SELECT SUM(DISTINCT pk_column_1) FROM table WHERE pk_column_2 = constant was not handled correctly. 
- Replication: Repeated execution of CHANGE MASTER 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. 
- Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead. 
- 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. 
- Directory name manipulation could result in stack overflow on Mac OS X and Windows.
- A buffer-handling problem in yaSSL was fixed. 
- It was possible in theory for UpdateXML() to return NULL incorrectly. 
- Metadata locking and table definition cache routines did not always check length of names passed to them. 
- Enabling the query cache during high client contention could cause the server to exit. 
- The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections. 
- Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. 
- For MEMORY tables with HASH indexes, DELETE sometimes failed to delete all applicable rows. 
- mysqld_safe used the nonportable -e test construct. 
- UNION type conversion could incorrectly turn unsigned values into signed values. 
- During the startup process, mysqld could incorrectly remove the PID file of an already running mysqld.