MySQL 歷史版本列表
MySQL (32-bit)MySQL (64-bit)MySQL WorkbenchMySQL Workbench (32-bit)MySQL Workbench (64-bit)
更新時間：2013-02-03
更新細節：
What's new in this version:
Functionality Added or Changed:
- InnoDB: The innodb_print_all_deadlocks configuration option from MySQL 5.6 was backported to MySQL 5.5. This option records each deadlock condition in the MySQL error log, allowing easier troubleshooting if frequent deadlocks point to application coding issues. (Bug #14515889)
- In RPM packages built for Unbreakable Linux Network, libmysqld.so now has a version number. (Bug #15972480)
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. (Bug #14676084)
- 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. (Bug #14329288, Bug #65886)
- 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. (Bug #14200010)
- 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. (Bug #11751825)
- 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: 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. (Bug #15859402, Bug #67476)
- 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. (Bug #15874001)
- InnoDB: The server could halt with an assertion error while creating an index: InnoDB: Assertion failure in thread thread_num in file row0merge.cc line 465
- 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. (Bug #14669848)
- InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation.
- 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: 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
- InnoDB: If the value of innodb_force_recovery was less than 6, opening a corrupted table might loop forever if a corrupted page was read when calculating statistics for the table. Information about the corrupted page was written repeatedly to the error log, possibly causing a disk space issue. The fix causes the server to halt after a fixed number of failed attempts to read the page. To troubleshoot such a corruption issue, set innodb_force_recovery=6 and restart. (Bug #14147491, Bug #65469)
- 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)
- Partitioning: Concurrent ALTER TABLE ... REBUILD PARTITION operations could interfere with one another, even when not running against the same table, because they both used global memory for storage. Now each partition rebuild operation stores intermediate data in memory that is local to that process. (Bug #14589559, Bug #66645)
- 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: After dropping a column from the slave's version of a table, then altering the same column of this table on the master (so that a type conversion would have been required had the column not been droppped on the slave), inserts into this table caused replication to fail. (Bug #15888454)
- Replication: When a binary log is replayed on a server (for example, by executing a command like mysqlbinlog binlog.000001 | mysql), it sets a pseudo-slave mode on the client connection used, so that the server can read binlog and apply binary log events correctly. However, the pseudo-slave mode was not disabled after the binary log dump was read, which caused unexpected filtering rules to be applied to SQL statements subsequently executed on the same connection. (Bug #15891524)
- Replication: When using statement-based replication, and where the master and the slave used table schemas having different AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT values logged for a given table on the master could be applied to the wrong table on the slave. (Bug #12669186)
- 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. (Bug #11764602, Bug #57454)
- 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: Dynamic file names (with colons) are no longer allowed. Static file names using the Alternate Data Stream (ADS) NTFS functionality of Microsoft Windows may continue to be used. (Bug #11761752)
- Directory name manipulation could result in stack overflow on Mac OS X and Windows. (Bug #16066243)
- Joins of exactly 32 tables and containing a HAVING clause returned an empty result. (Bug #15972635)
- A buffer-handling problem in yaSSL was fixed. (Bug #15965288)
- A mysys library string-formatting routine could mishandle width specifiers. (Bug #15960005)
- In certain cases, UpdateXML() could return NULL incorrectly. (Bug #15948580)
- References: See also Bug #13007062.
- Metadata locking and table definition cache routines did not always check length of names passed to them. (Bug #15954872)
- XA START had a race condition that could cause a server crash. (Bug #14729757)
- Enabling the query cache during high client contention could cause the server to exit. (Bug #14727815)
- There was a performance regression for queries using SELECT ... INTO user variables and a WHERE condition on one or more of the variables in the INTO list. (Bug #14664077)
- References: This bug was introduced by Bug #12408412.
- The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug #14627287)
- Output generated with mysqldump --routines could produce syntax errors when reloaded. (Bug #14463669)
- With the thread pool plugin installed, a workload consisting of concurrent KILL statements and ping queries caused the server to exit. (Bug #14458232, Bug #14458002)
- CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error. (Bug #13556107, Bug #13556000)
- Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. (Bug #12347040)
- For dumps of the mysql database, mysqldump skipped the event table unless the --events option was given. To skip this table if that is desired, use the --ignore-table option instead (Bug #55587, Bug #11762933)
- For MEMORY tables with HASH indexes, DELETE sometimes failed to delete all applicable rows. (Bug #51763, Bug #11759445)
- The mysql client could mishandle the delimiter command if it occurred on a line during which mysql was looking for the end of a quoted string. (Bug #64135, Bug #13639125)
- mysqld_safe used the nonportable -e test construct. (Bug #67976, Bug #16046140)
- Configuring the server with performance_schema_events_waits_history_size=0 and performance_schema_events_waits_history_long_size=0 could cause a Performance Schema segmentation fault. (Bug #68008, Bug #16060864)
- DECIMAL multiplication operations could produce significant inaccuracy. (Bug #45860, Bug #11754279)
- For subqueries executing using a filesort, the optimizer could produce an incorrect result containing wrong rows. (Bug #66845, Bug #14636211)
- References: See also Bug #12667154.
- UNION type conversion could incorrectly turn unsigned values into signed values. (Bug #49003, Bug #11757005)
- During the startup process, mysqld could incorrectly remove the PID file of an already running mysqld. (Bug #23790, Bug #11746142)
更新時間：2013-02-03
更新細節：
What's new in this version:
Functionality Added or Changed:
- InnoDB: The innodb_print_all_deadlocks configuration option from MySQL 5.6 was backported to MySQL 5.5. This option records each deadlock condition in the MySQL error log, allowing easier troubleshooting if frequent deadlocks point to application coding issues. (Bug #14515889)
- In RPM packages built for Unbreakable Linux Network, libmysqld.so now has a version number. (Bug #15972480)
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. (Bug #14676084)
- 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. (Bug #14329288, Bug #65886)
- 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. (Bug #14200010)
- 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. (Bug #11751825)
- 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: 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. (Bug #15859402, Bug #67476)
- 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. (Bug #15874001)
- InnoDB: The server could halt with an assertion error while creating an index: InnoDB: Assertion failure in thread thread_num in file row0merge.cc line 465
- 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. (Bug #14669848)
- InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation.
- 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: 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
- InnoDB: If the value of innodb_force_recovery was less than 6, opening a corrupted table might loop forever if a corrupted page was read when calculating statistics for the table. Information about the corrupted page was written repeatedly to the error log, possibly causing a disk space issue. The fix causes the server to halt after a fixed number of failed attempts to read the page. To troubleshoot such a corruption issue, set innodb_force_recovery=6 and restart. (Bug #14147491, Bug #65469)
- 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)
- Partitioning: Concurrent ALTER TABLE ... REBUILD PARTITION operations could interfere with one another, even when not running against the same table, because they both used global memory for storage. Now each partition rebuild operation stores intermediate data in memory that is local to that process. (Bug #14589559, Bug #66645)
- 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: After dropping a column from the slave's version of a table, then altering the same column of this table on the master (so that a type conversion would have been required had the column not been droppped on the slave), inserts into this table caused replication to fail. (Bug #15888454)
- Replication: When a binary log is replayed on a server (for example, by executing a command like mysqlbinlog binlog.000001 | mysql), it sets a pseudo-slave mode on the client connection used, so that the server can read binlog and apply binary log events correctly. However, the pseudo-slave mode was not disabled after the binary log dump was read, which caused unexpected filtering rules to be applied to SQL statements subsequently executed on the same connection. (Bug #15891524)
- Replication: When using statement-based replication, and where the master and the slave used table schemas having different AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT values logged for a given table on the master could be applied to the wrong table on the slave. (Bug #12669186)
- 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. (Bug #11764602, Bug #57454)
- 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: Dynamic file names (with colons) are no longer allowed. Static file names using the Alternate Data Stream (ADS) NTFS functionality of Microsoft Windows may continue to be used. (Bug #11761752)
- Directory name manipulation could result in stack overflow on Mac OS X and Windows. (Bug #16066243)
- Joins of exactly 32 tables and containing a HAVING clause returned an empty result. (Bug #15972635)
- A buffer-handling problem in yaSSL was fixed. (Bug #15965288)
- A mysys library string-formatting routine could mishandle width specifiers. (Bug #15960005)
- In certain cases, UpdateXML() could return NULL incorrectly. (Bug #15948580)
- References: See also Bug #13007062.
- Metadata locking and table definition cache routines did not always check length of names passed to them. (Bug #15954872)
- XA START had a race condition that could cause a server crash. (Bug #14729757)
- Enabling the query cache during high client contention could cause the server to exit. (Bug #14727815)
- There was a performance regression for queries using SELECT ... INTO user variables and a WHERE condition on one or more of the variables in the INTO list. (Bug #14664077)
- References: This bug was introduced by Bug #12408412.
- The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug #14627287)
- Output generated with mysqldump --routines could produce syntax errors when reloaded. (Bug #14463669)
- With the thread pool plugin installed, a workload consisting of concurrent KILL statements and ping queries caused the server to exit. (Bug #14458232, Bug #14458002)
- CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error. (Bug #13556107, Bug #13556000)
- Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. (Bug #12347040)
- For dumps of the mysql database, mysqldump skipped the event table unless the --events option was given. To skip this table if that is desired, use the --ignore-table option instead (Bug #55587, Bug #11762933)
- For MEMORY tables with HASH indexes, DELETE sometimes failed to delete all applicable rows. (Bug #51763, Bug #11759445)
- The mysql client could mishandle the delimiter command if it occurred on a line during which mysql was looking for the end of a quoted string. (Bug #64135, Bug #13639125)
- mysqld_safe used the nonportable -e test construct. (Bug #67976, Bug #16046140)
- Configuring the server with performance_schema_events_waits_history_size=0 and performance_schema_events_waits_history_long_size=0 could cause a Performance Schema segmentation fault. (Bug #68008, Bug #16060864)
- DECIMAL multiplication operations could produce significant inaccuracy. (Bug #45860, Bug #11754279)
- For subqueries executing using a filesort, the optimizer could produce an incorrect result containing wrong rows. (Bug #66845, Bug #14636211)
- References: See also Bug #12667154.
- UNION type conversion could incorrectly turn unsigned values into signed values. (Bug #49003, Bug #11757005)
- During the startup process, mysqld could incorrectly remove the PID file of an already running mysqld. (Bug #23790, Bug #11746142)
更新時間：2012-12-21
更新細節：
更新時間：2012-12-21
更新細節：
What's new in this version:
Functionality Added or Changed:
- The SHOW AUTHORS and SHOW CONTRIBUTORS statements are now deprecated in MySQL 5.5 and have been removed in MySQL 5.6.
Bugs Fixed:
- Performance: InnoDB: The timing values for low-level InnoDB read operations were adjusted for better performance with fast storage devices, such as SSD. This enhancement primarily affects read operations for BLOB columns in compressed tables.
- Important Change: InnoDB: A DML statement using the index merge access method could lock many rows from the table, even when those rows were not part of the final result set. This fix reduces the excessive locking by releasing the locks of unmatched rows. This optimization affects only transactions with isolation level equal to or less strict than READ COMMITTED; it does not apply to transactions using REPEATABLE READ or SERIALIZABLE isolation level.
- InnoDB: An online DDL operation for an InnoDB table incorrectly reported an empty value ('') instead of the correct key value when it reported a duplicate key error for a unique index using an index prefix.
- InnoDB: If a CREATE TABLE statement failed due to a disk full error, some memory allocated during the operation was not freed properly.
- InnoDB: With the innodb_file_per_table setting enabled, a DROP TABLE operation could cause a crash, due to a race condition that depended on the timing of pending I/O requests.
- InnoDB: If the server crashed at the specific point when a change buffer entry was being merged into a buffer pool page, the transaction log and the change buffer were left in an inconsistent state. After a restart, MySQL could crash after reading the corresponding secondary index page. The problem was more likely to occur in MySQL 5.5 or later, where the original insert buffering mechanism was generalized to cover other operations.
- InnoDB: Inserting data of varying record lengths into an InnoDB table that used compression could cause the server to halt with an error.
- InnoDB: If a table was defined with an index key length very close to the upper length limit of 3072, a query against that table could cause a serious error.
- InnoDB: When an auto-increment column used a FLOAT or DOUBLE data type, if the auto-increment value became very large (larger than the maximum unsigned long long value), subsequent inserts could fail or cause the server to halt.
- InnoDB: If a transaction was started with a consistent snapshot, then new indexes were added to the table while the transaction was in progress, a subsequent UPDATE statement could incorrectly encounter the error:
- HA_ERR_TABLE_DEF_CHANGED: insufficient history for index
- This issue could cause an assertion error in debug builds.
- InnoDB: The error message was improved for the case where an UPDATE failed because the row included several BLOB values greater than 768 bytes each, causing the size of a row to exceed half the page size. The old message, was misleading; it suggested using BLOBs, when the 768-byte prefix for each BLOB column was the cause of the limit error:
- Error Code 1118: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs
- A workaround for the problem was to create the table with the ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED clause, which is now suggested in the message.
- InnoDB: In rare circumstances, MySQL could apply InnoDB undo records out of order during a ROLLBACK of an operation that modified a BLOB column. This issue could cause an assertion error in debug builds:
- !bpage->file_page_was_freed
- Replication: Updates writing user variables whose values were never set on a slave while using --replicate-ignore-table could cause the slave to fail.
- Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave.
- Replication: Following an insert into a nontransactional table that failed due to insufficient disk space, the server did not properly clean up all pending events, leading to an assert or possibly to other errors.
- Very long database names in queries could cause the server to exit.
- Within a stored procedure, executing a multiple-table DELETE statement that used a very long table alias could cause the server to exit.
- Very long table aliases in queries could cause the server to exit.
- Attempting to create an auto-increment column in an InnoDB table with a NULL type attribute could cause a serious error.
- A DELETE statement for an InnoDB table could write incorrect transaction metadata into a record, causing the server to halt with an error. To work around this issue, reduce the specified length of the primary key to less than 1K bytes.
- Repeated execution of a query containing a subquery that used MAX() could result in increasing memory consumption.
- USE dbname could fail with Unknown database when dbname contained multiple backtick (`) characters.
- The configure.pl script that converts GNU configure options to CMake equivalents generated erroneous output for the --with-client-ldflags and --with-mysqld-ldflags options. It now ignores those options.
- SHOW PROFILE could be used to cause excessive server memory consumption.
- The thread cache implementation worked in LIFO rather than FIFO fashion and could result in a thread being denied service (although this was a remote possibility).
- Within a stored program, memory allocated to hold condition information was not released until program exit, leading to excessive memory use.
- Improper memory cleanup could cause the server to exit.
- Granting or revoking the PROXY privilege caused the server to exit if the server was started with --skip-name-resolve.
- CREATE USER and DROP USER could fail to flush the privileges, requiring FLUSH PRIVILEGES to be used explicitly.
- Access to INFORMATION_SCHEMA tables through a view could leak memory.
- A memory leak could occur for queries containing a subquery that used GROUP BY on an outer column.
- On Microsoft Windows with CMake 2.6, the build process would not stop if the create_initial_db step failed.
- The test in mysqld_safe for the presence of the --plugin_dir option and assignment of a default value to it were performed before the actual argument parsing took place.
- CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error.
- Improper memory cleanup could cause the server to exit.
- A memory leak occurred due to failure to clean up after QUICK_INDEX_MERGE_SELECT/Unique.
- The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect.
- During optimization, ZEROFILL values may be converted to string constants. However, CASE expressions did not handle switching data types after the planning stage, leading to CASE finding a null pointer instead of its argument.
- In debug builds, an InnoDB assertion was overly aggressive about prohibiting an open range.
- On Windows, the Perl version of mysql_install_db created system tables in the mysql database that were not populated properly.
- mysqld_safe ignored the value of the UMASK environment variable, leading to behavior different from mysqld with respect to the access mode of created files. Now mysqld_safe (and mysqld_multi) attempt to approximate the same behavior as mysqld.
- LAST_INSERT_ID(expr) did not work for expr values greater than the largest signed BIGINT value.
更新時間：2012-12-21
更新細節：
What's new in this version:
Functionality Added or Changed:
- The SHOW AUTHORS and SHOW CONTRIBUTORS statements are now deprecated in MySQL 5.5 and have been removed in MySQL 5.6.
Bugs Fixed:
- Performance: InnoDB: The timing values for low-level InnoDB read operations were adjusted for better performance with fast storage devices, such as SSD. This enhancement primarily affects read operations for BLOB columns in compressed tables.
- Important Change: InnoDB: A DML statement using the index merge access method could lock many rows from the table, even when those rows were not part of the final result set. This fix reduces the excessive locking by releasing the locks of unmatched rows. This optimization affects only transactions with isolation level equal to or less strict than READ COMMITTED; it does not apply to transactions using REPEATABLE READ or SERIALIZABLE isolation level.
- InnoDB: An online DDL operation for an InnoDB table incorrectly reported an empty value ('') instead of the correct key value when it reported a duplicate key error for a unique index using an index prefix.
- InnoDB: If a CREATE TABLE statement failed due to a disk full error, some memory allocated during the operation was not freed properly.
- InnoDB: With the innodb_file_per_table setting enabled, a DROP TABLE operation could cause a crash, due to a race condition that depended on the timing of pending I/O requests.
- InnoDB: If the server crashed at the specific point when a change buffer entry was being merged into a buffer pool page, the transaction log and the change buffer were left in an inconsistent state. After a restart, MySQL could crash after reading the corresponding secondary index page. The problem was more likely to occur in MySQL 5.5 or later, where the original insert buffering mechanism was generalized to cover other operations.
- InnoDB: Inserting data of varying record lengths into an InnoDB table that used compression could cause the server to halt with an error.
- InnoDB: If a table was defined with an index key length very close to the upper length limit of 3072, a query against that table could cause a serious error.
- InnoDB: When an auto-increment column used a FLOAT or DOUBLE data type, if the auto-increment value became very large (larger than the maximum unsigned long long value), subsequent inserts could fail or cause the server to halt.
- InnoDB: If a transaction was started with a consistent snapshot, then new indexes were added to the table while the transaction was in progress, a subsequent UPDATE statement could incorrectly encounter the error:
- HA_ERR_TABLE_DEF_CHANGED: insufficient history for index
- This issue could cause an assertion error in debug builds.
- InnoDB: The error message was improved for the case where an UPDATE failed because the row included several BLOB values greater than 768 bytes each, causing the size of a row to exceed half the page size. The old message, was misleading; it suggested using BLOBs, when the 768-byte prefix for each BLOB column was the cause of the limit error:
- Error Code 1118: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs
- A workaround for the problem was to create the table with the ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED clause, which is now suggested in the message.
- InnoDB: In rare circumstances, MySQL could apply InnoDB undo records out of order during a ROLLBACK of an operation that modified a BLOB column. This issue could cause an assertion error in debug builds:
- !bpage->file_page_was_freed
- Replication: Updates writing user variables whose values were never set on a slave while using --replicate-ignore-table could cause the slave to fail.
- Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave.
- Replication: Following an insert into a nontransactional table that failed due to insufficient disk space, the server did not properly clean up all pending events, leading to an assert or possibly to other errors.
- Very long database names in queries could cause the server to exit.
- Within a stored procedure, executing a multiple-table DELETE statement that used a very long table alias could cause the server to exit.
- Very long table aliases in queries could cause the server to exit.
- Attempting to create an auto-increment column in an InnoDB table with a NULL type attribute could cause a serious error.
- A DELETE statement for an InnoDB table could write incorrect transaction metadata into a record, causing the server to halt with an error. To work around this issue, reduce the specified length of the primary key to less than 1K bytes.
- Repeated execution of a query containing a subquery that used MAX() could result in increasing memory consumption.
- USE dbname could fail with Unknown database when dbname contained multiple backtick (`) characters.
- The configure.pl script that converts GNU configure options to CMake equivalents generated erroneous output for the --with-client-ldflags and --with-mysqld-ldflags options. It now ignores those options.
- SHOW PROFILE could be used to cause excessive server memory consumption.
- The thread cache implementation worked in LIFO rather than FIFO fashion and could result in a thread being denied service (although this was a remote possibility).
- Within a stored program, memory allocated to hold condition information was not released until program exit, leading to excessive memory use.
- Improper memory cleanup could cause the server to exit.
- Granting or revoking the PROXY privilege caused the server to exit if the server was started with --skip-name-resolve.
- CREATE USER and DROP USER could fail to flush the privileges, requiring FLUSH PRIVILEGES to be used explicitly.
- Access to INFORMATION_SCHEMA tables through a view could leak memory.
- A memory leak could occur for queries containing a subquery that used GROUP BY on an outer column.
- On Microsoft Windows with CMake 2.6, the build process would not stop if the create_initial_db step failed.
- The test in mysqld_safe for the presence of the --plugin_dir option and assignment of a default value to it were performed before the actual argument parsing took place.
- CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error.
- Improper memory cleanup could cause the server to exit.
- A memory leak occurred due to failure to clean up after QUICK_INDEX_MERGE_SELECT/Unique.
- The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect.
- During optimization, ZEROFILL values may be converted to string constants. However, CASE expressions did not handle switching data types after the planning stage, leading to CASE finding a null pointer instead of its argument.
- In debug builds, an InnoDB assertion was overly aggressive about prohibiting an open range.
- On Windows, the Perl version of mysql_install_db created system tables in the mysql database that were not populated properly.
- mysqld_safe ignored the value of the UMASK environment variable, leading to behavior different from mysqld with respect to the access mode of created files. Now mysqld_safe (and mysqld_multi) attempt to approximate the same behavior as mysqld.
- LAST_INSERT_ID(expr) did not work for expr values greater than the largest signed BIGINT value.
更新時間：2012-10-01
更新細節：
What's new in this version:
- InnoDB: Certain information_schema tables originally introduced in MySQL 5.6 are now also available in MySQL 5.5 and MySQL 5.1: INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS.
- InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL statement scanned rows in an InnoDB table using a < or <= operator in a WHERE clause, the next row after the affected range could also be locked. This issue could cause a lock wait timeout for a row that was not expected to be locked. The issue occurred under various isolation levels, such as READ COMMITTED and REPEATABLE READ.
- Partitioning: The buffer for the row currently read from each partition used for sorted reads was allocated on open and freed only when the partitioning handler was closed or destroyed. For SELECT statements on tables with many partitions and large rows, this could cause the server to use excessive amounts of memory. This issue has been addressed by allocating buffers for reads from partitioned tables only when they are needed and freeing them immediately once they are no longer needed. As part of this fix, memory is now allocated for reading from rows only in partitions that have not been pruned.
- Replication: In master-master replication with --log-slave-updates enabled, setting a user variable and then performing inserts using this variable caused the Exec_master_log_position column in the output of SHOW SLAVE STATUS not to be updated.
- Small sort_buffer_size values could result in a server crash.
- The libmysqlclient_r client library exported symbols from yaSSL that conflict with OpenSSL. If a program linked against that library and libcurl, it could crash with a segmentation fault.
- The argument for LIMIT must be an integer, but if the argument was given by a placeholder in a prepared statement, the server did not reject noninteger values such as '5'.
- Access to INFORMATION_SCHEMA tables through a view could leak memory.
- A query for a FEDERATED table could return incorrect results when the underlying table had a compound index on two columns and the query included an AND condition on the columns.
- The argument to the --ssl-key option was not verified to exist and be a valid key. The resulting connection used SSL, but the key was not used.
- In debug builds, an InnoDB assertion was overly aggressive about prohibiting an open range.
- Adding a LIMIT clause to a query containing GROUP BY and ORDER BY could cause the optimizer to choose an incorrect index for processing the query, and return more rows than required.
- mysqlbinlog did not accept input on the standard input when the standard input was a pipe.
更新時間：2012-09-29
更新細節：
What's new in this version:
Audit Log Plugin Notes:
- MySQL Enterprise Edition subscriptions now include MySQL Enterprise Audit, implemented using a server plugin named audit_log. MySQL Enterprise Audit uses the open MySQL Audit API to enable standard, policy-based monitoring and logging of connection and query activity executed on specific MySQL servers. Designed to meet the Oracle audit specification, MySQL Enterprise Audit provides an out of box, easy to use auditing and compliance solution for applications that are governed by both internal and external regulatory guidelines.
- When installed, the audit_log plugin enables MySQL Server to produce a log file containing an audit record of server activity. The log contents include when clients connect and disconnect, and what actions they perform while connected, such as which databases and tables they access. Functionality Added or Changed:
- The internal interface of the Thread Pool plugin has changed. Old versions of the plugin will work with current versions of the server, but versions of the server older than 5.5.28 will not work with current versions of the plugin. Bugs Fixed:
- InnoDB: Certain information_schema tables originally introduced in MySQL 5.6 are now also available in MySQL 5.5 and MySQL 5.1: INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS. (Bug #13113026)
- InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL statement scanned rows in an InnoDB table using an operator in a WHERE clause, the next row after the affected range could also be locked. This issue could cause a lock wait timeout for a row that was not expected to be locked. The issue occurred under various isolation levels, such as READ COMMITTED and REPEATABLE READ. (Bug #11765218)
- Partitioning: For tables using PARTITION BY HASH or PARTITION BY KEY, when the partition pruning mechanism encountered a multi-range list or inequality using a column from the partitioning key, it continued with the next partitioning column and tried to use it for pruning, even if the previous column could not be used. This caused partitions which possibly matched one or more of the previous partitioning columns to be pruned away, leaving partitions that matched only the last column of the partitioning key.
This issue was triggered when both of the following conditions were met:
- The columns making up the table's partitioning key were used in the same order as in the partitioning key definition by a SELECT statement's WHERE clause as in the column definitions;
- The WHERE condition used with the last column of the partitioning key was satisfied only by a single value, while the condition testing some previous column from the partitioning key was satisfied by a range of values.
- This issue is resolved by ensuring that partition pruning skips any remaining partitioning key columns once a partition key column that cannot be used in pruning is encountered. (Bug #14342883)
- Partitioning: The buffer for the row currently read from each partition used for sorted reads was allocated on open and freed only when the partitioning handler was closed or destroyed. For SELECT statements on tables with many partitions and large rows, this could cause the server to use excessive amounts of memory.
- This issue has been addressed by allocating buffers for reads from partitioned tables only when they are needed and freeing them immediately once they are no longer needed. As part of this fix, memory is now allocated for reading from rows only in partitions that have not been pruned (see Section 18.4, “Partition Pruning”). (Bug #13025132)
- References: See also Bug #11764622, Bug #14537277.
- Replication: On 64-bit Windows platforms, values greater than 4G for the max_binlog_cache_size and max_binlog_stmt_cache_size system variables were truncated to 4G. This caused LOAD DATA INFILE to fail when trying to load a file larger than 4G in size, even when max_binlog_cache_size was set to a value greater than this. (Bug #13961678)
- Replication: In master-master replication with --log-slave-updates enabled, setting a user variable and then performing inserts using this variable caused the Exec_master_log_position column in the output of SHOW SLAVE STATUS not to be updated. (Bug #13596613)
- The RPM spec file now also runs the test suite on the new binaries, before packaging them. (Bug #14318456)
- The libmysqlclient_r client library exported symbols from yaSSL that conflict with OpenSSL. If a program linked against that library and libcurl, it could crash with a segmentation fault. (Bug #14068244)
- The argument for LIMIT must be an integer, but if the argument was given by a placeholder in a prepared statement, the server did not reject noninteger values such as '5'. (Bug #13868860)
- The Thread Pool plugin did not respect the wait_timeout timeout for client sessions. (Bug #13699303)
- CHECK TABLE and REPAIR TABLE could crash if a key definition differed in the .frm and .MYI files of a MyISAM table. Now the server produces an error. (Bug #13555854)
- A query for a FEDERATED table could return incorrect results when the underlying table had a compound index on two columns and the query included an AND condition on the columns. (Bug #12876932)
- mysqlhotcopy failed for databases containing views. (Bug #62472, Bug #13006947, Bug #12992993)
- The argument to the --ssl-key option was not verified to exist and be a valid key. The resulting connection used SSL, but the key was not used. (Bug #62743, Bug #13115401)
- Adding a LIMIT clause to a query containing GROUP BY and ORDER BY could cause the optimizer to choose an incorrect index for processing the query, and return more rows than required. (Bug #54599, Bug #11762052)
- mysqlbinlog did not accept input on the standard input when the standard input was a pipe. (Bug #49336, Bug #11757312)
更新時間：2012-09-29
更新細節：
What's new in this version:
Audit Log Plugin Notes:
- MySQL Enterprise Edition subscriptions now include MySQL Enterprise Audit, implemented using a server plugin named audit_log. MySQL Enterprise Audit uses the open MySQL Audit API to enable standard, policy-based monitoring and logging of connection and query activity executed on specific MySQL servers. Designed to meet the Oracle audit specification, MySQL Enterprise Audit provides an out of box, easy to use auditing and compliance solution for applications that are governed by both internal and external regulatory guidelines.
- When installed, the audit_log plugin enables MySQL Server to produce a log file containing an audit record of server activity. The log contents include when clients connect and disconnect, and what actions they perform while connected, such as which databases and tables they access. Functionality Added or Changed:
- The internal interface of the Thread Pool plugin has changed. Old versions of the plugin will work with current versions of the server, but versions of the server older than 5.5.28 will not work with current versions of the plugin. Bugs Fixed:
- InnoDB: Certain information_schema tables originally introduced in MySQL 5.6 are now also available in MySQL 5.5 and MySQL 5.1: INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS. (Bug #13113026)
- InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL statement scanned rows in an InnoDB table using an operator in a WHERE clause, the next row after the affected range could also be locked. This issue could cause a lock wait timeout for a row that was not expected to be locked. The issue occurred under various isolation levels, such as READ COMMITTED and REPEATABLE READ. (Bug #11765218)
- Partitioning: For tables using PARTITION BY HASH or PARTITION BY KEY, when the partition pruning mechanism encountered a multi-range list or inequality using a column from the partitioning key, it continued with the next partitioning column and tried to use it for pruning, even if the previous column could not be used. This caused partitions which possibly matched one or more of the previous partitioning columns to be pruned away, leaving partitions that matched only the last column of the partitioning key.
This issue was triggered when both of the following conditions were met:
- The columns making up the table's partitioning key were used in the same order as in the partitioning key definition by a SELECT statement's WHERE clause as in the column definitions;
- The WHERE condition used with the last column of the partitioning key was satisfied only by a single value, while the condition testing some previous column from the partitioning key was satisfied by a range of values.
- This issue is resolved by ensuring that partition pruning skips any remaining partitioning key columns once a partition key column that cannot be used in pruning is encountered. (Bug #14342883)
- Partitioning: The buffer for the row currently read from each partition used for sorted reads was allocated on open and freed only when the partitioning handler was closed or destroyed. For SELECT statements on tables with many partitions and large rows, this could cause the server to use excessive amounts of memory.
- This issue has been addressed by allocating buffers for reads from partitioned tables only when they are needed and freeing them immediately once they are no longer needed. As part of this fix, memory is now allocated for reading from rows only in partitions that have not been pruned (see Section 18.4, “Partition Pruning”). (Bug #13025132)
- References: See also Bug #11764622, Bug #14537277.
- Replication: On 64-bit Windows platforms, values greater than 4G for the max_binlog_cache_size and max_binlog_stmt_cache_size system variables were truncated to 4G. This caused LOAD DATA INFILE to fail when trying to load a file larger than 4G in size, even when max_binlog_cache_size was set to a value greater than this. (Bug #13961678)
- Replication: In master-master replication with --log-slave-updates enabled, setting a user variable and then performing inserts using this variable caused the Exec_master_log_position column in the output of SHOW SLAVE STATUS not to be updated. (Bug #13596613)
- The RPM spec file now also runs the test suite on the new binaries, before packaging them. (Bug #14318456)
- The libmysqlclient_r client library exported symbols from yaSSL that conflict with OpenSSL. If a program linked against that library and libcurl, it could crash with a segmentation fault. (Bug #14068244)
- The argument for LIMIT must be an integer, but if the argument was given by a placeholder in a prepared statement, the server did not reject noninteger values such as '5'. (Bug #13868860)
- The Thread Pool plugin did not respect the wait_timeout timeout for client sessions. (Bug #13699303)
- CHECK TABLE and REPAIR TABLE could crash if a key definition differed in the .frm and .MYI files of a MyISAM table. Now the server produces an error. (Bug #13555854)
- A query for a FEDERATED table could return incorrect results when the underlying table had a compound index on two columns and the query included an AND condition on the columns. (Bug #12876932)
- mysqlhotcopy failed for databases containing views. (Bug #62472, Bug #13006947, Bug #12992993)
- The argument to the --ssl-key option was not verified to exist and be a valid key. The resulting connection used SSL, but the key was not used. (Bug #62743, Bug #13115401)
- Adding a LIMIT clause to a query containing GROUP BY and ORDER BY could cause the optimizer to choose an incorrect index for processing the query, and return more rows than required. (Bug #54599, Bug #11762052)
- mysqlbinlog did not accept input on the standard input when the standard input was a pipe. (Bug #49336, Bug #11757312)
更新時間：2012-08-10
更新細節：
What's new in this version:
- Important Change: The YEAR(2) data type is now deprecated because it is problematic. Support for YEAR(2) will be removed in a future release of MySQL.
更新時間：2012-08-06
更新細節：
What's new in this version:
* Functionality Added or Changed
- Important Change: The YEAR(2) data type is now deprecated because it is problematic. Support for YEAR(2) will be removed in a future release of MySQL.
* Bugs Fixed
- InnoDB: A race condition could cause assertion errors during a DROP TABLE statement for an InnoDB table. Some internal InnoDB functions did not correctly determine if a tablespace was missing; other functions did not handle the error code correctly if a tablespace was missing.
- InnoDB: If a row was deleted from an InnoDB table, then another row was re-inserted with the same primary key value, an attempt by a concurrent transaction to lock the row could succeed when it should have waited. This issue occurred if the locking select used a WHERE clause that performed an index scan using a secondary index.
- InnoDB: An assertion could be raised if an InnoDB table was moved to a different database using ALTER TABLE ... RENAME while the database was being dropped by DROP DATABASE.
- InnoDB: Using the KILL statement to terminate a query could cause an unnecessary message in the error log: [ERROR] Got error -1 when reading table table_name
- InnoDB: For an InnoDB table with a trigger, under the setting innodb_autoinc_lock_mode=1, sometimes auto-increment values could be interleaved when inserting into the table from two sessions concurrently. The sequence of auto-increment values could vary depending on timing, leading to data inconsistency in systems using replication.
- Replication: An event whose length exceeded the size of the master dump thread's max_allowed_packet caused replication to fail. This could occur when updating many large rows and using row-based replication. As part of this fix, a new server option --slave-max-allowed-packet is added, which permits max_allowed_packet to be exceeded by the slave SQL and I/O threads. Now the size of a packet transmitted from the master to the slave is checked only against this value (available as the value of the slave_max_allowed_packet server system variable), and not against the value of max_allowed_packet.
- Replication: Statements such as UPDATE ... WHERE primary_key_column = constant LIMIT 1 are flagged as unsafe for statement-based logging, despite the fact that such statements are actually safe. In cases where a great many such statements were run, this could lead to disk space becoming exhausted do to the number of such false warnings being logged. To prevent this from happening, a warning suppression mechanism is introduced. This warning suppression acts as follows: Whenever the 50 most recent ER_BINLOG_UNSAFE_STATEMENT warnings have been generated more than 50 times in any 50-second period, warning suppression is enabled. When activated, this causes such warnings not to be written to the error log; instead, for each 50 warnings of this type, a note is written to the error log stating The last warning was repeated N times in last S seconds. This continues as long as the 50 most recent such warnings were issued in 50 seconds or less; once the number of warnings has decreased below this threshold, the warnings are once again logged normally. The fix for this issue does not affect how these warnings are reported to MySQL clients; a warning is still sent to the client for each statement that generates the warning. This fix also does not make any changes in how the safety of any statement for statement-based logging is determined.
- Replication: After upgrading a replication slave to MySQL 5.5.18 or later, enabling the query cache eventually caused the slave to fail.
- The server did not build with gcc 4.7.
- Certain arguments to RPAD() could lead to “uninitialized variable” warnings.
- The presence of a file named .empty in the test database prevented that database from being dropped.
- For some subqueries that should be executed using a range scan on a non-primary index and required use of filesort, only the first execution of the subquery was done as a range scan. All following executions were done as full table scans, resulting in poor performance.
- The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect.
- File access by the ARCHIVE storage engine was not instrumented and thus not shown in Performance Schema tables.
- mysqlbinlog exited with no error code if file write errors occurred.
- Using CONCAT() to construct a pattern for a LIKE pattern match could result in memory corrupting and match failure.
- yaSSL rejected valid SSL certificates that OpenSSL accepts.
- Sessions could end up deadlocked when executing a combination of SELECT, DROP TABLE, KILL, and SHOW ENGINE INNODB STATUS.
- mysqldump could dump views and the tables on which they depend in such an order that errors occurred when the dump file was reloaded.