MySQL 歷史版本列表 Page44

更新時間：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.

更新時間：2012-07-08
更新細節：

What's new in this version:

Bugs Fixed:
- A regression bug in the optimizer could cause excessive disk usage for UPDATE statements.

更新時間：2012-07-07
更新細節：

What's new in this version:

Bugs Fixed:
- A regression bug in the optimizer could cause excessive disk usage for UPDATE statements.

更新時間：2012-06-01
更新細節：

What's new in this version:

Functionality Added or Changed:
- The --safe-mode server option now is deprecated and will be removed in MySQL 5.6.

Bugs Fixed:
- Performance: InnoDB: Improved the algorithm related to adaptive flushing. This fix increases the rate of flushing in cases where compression is used and the data set is larger than the buffer pool, leading to eviction.
- InnoDB: In a transaction using the REPEATABLE READ isolation level, an UPDATE or DELETE statement for an InnoDB table could sometimes overlook rows recently committed by other transactions. As explained in Section 14.3.9.2, “Consistent Nonlocking Reads”, DML statements within a REPEATABLE READ transaction apply to rows committed by other transactions, even if a query could not see those rows.
- InnoDB: The Innodb_buffer_pool_pages_flushed status variable was incorrectly set to twice the value it should be. Its value should never exceed the value of Innodb_pages_written.
- InnoDB: The error handling and message was improved for attempting to create a foreign key with a column referencing itself. The message suggested a potential problem with the data dictionary, when no such problem existed.
- InnoDB: The CHECK TABLE statement could fail for a large InnoDB table due to a timeout value of 2 hours. For typical storage devices, the issue could occur for tables that exceeded approximately 200 or 350 GB, depending on I/O speed. The fix relaxes the locking performed on the table being checked, which makes the timeout less likely. It also makes InnoDB recognize the syntax CHECK TABLE QUICK, which avoids the possibility of the timeout entirely.
- Replication: It was theoretically possible for concurrent execution of more than one instance of SHOW BINLOG EVENTS to crash the MySQL Server.
- Replication: Statements using AUTO_INCREMENT, LAST_INSERT_ID(), RAND(), or user variables could be applied in the wrong context on the slave when using statement-based replication and replication filtering server options
- Replication: An INSERT into a table that has a composite primary key that includes an AUTO_INCREMENT column that is not the first column of this composite key is not safe for statement-based binary logging or replication. Such statements are now marked as unsafe and fail with an error when using the STATEMENT binary logging format.
- SHOW TABLES was very slow unless the required information was already in the disk cache.

更新時間：2012-06-01
更新細節：

What's new in this version:

Functionality Added or Changed:
- The --safe-mode server option now is deprecated and will be removed in MySQL 5.6.

Bugs Fixed:
- Performance: InnoDB: Improved the algorithm related to adaptive flushing. This fix increases the rate of flushing in cases where compression is used and the data set is larger than the buffer pool, leading to eviction.
- InnoDB: In a transaction using the REPEATABLE READ isolation level, an UPDATE or DELETE statement for an InnoDB table could sometimes overlook rows recently committed by other transactions. As explained in Section 14.3.9.2, “Consistent Nonlocking Reads”, DML statements within a REPEATABLE READ transaction apply to rows committed by other transactions, even if a query could not see those rows.
- InnoDB: The Innodb_buffer_pool_pages_flushed status variable was incorrectly set to twice the value it should be. Its value should never exceed the value of Innodb_pages_written.
- InnoDB: The error handling and message was improved for attempting to create a foreign key with a column referencing itself. The message suggested a potential problem with the data dictionary, when no such problem existed.
- InnoDB: The CHECK TABLE statement could fail for a large InnoDB table due to a timeout value of 2 hours. For typical storage devices, the issue could occur for tables that exceeded approximately 200 or 350 GB, depending on I/O speed. The fix relaxes the locking performed on the table being checked, which makes the timeout less likely. It also makes InnoDB recognize the syntax CHECK TABLE QUICK, which avoids the possibility of the timeout entirely.
- Replication: It was theoretically possible for concurrent execution of more than one instance of SHOW BINLOG EVENTS to crash the MySQL Server.
- Replication: Statements using AUTO_INCREMENT, LAST_INSERT_ID(), RAND(), or user variables could be applied in the wrong context on the slave when using statement-based replication and replication filtering server options
- Replication: An INSERT into a table that has a composite primary key that includes an AUTO_INCREMENT column that is not the first column of this composite key is not safe for statement-based binary logging or replication. Such statements are now marked as unsafe and fail with an error when using the STATEMENT binary logging format.
- SHOW TABLES was very slow unless the required information was already in the disk cache.

更新時間：2012-05-09
更新細節：

What's new in this version:

- Security Fix: Bug #64884 was fixed.
- Security Fix: Bug #59387 was fixed.
- InnoDB: Deleting a huge amount of data from InnoDB tables within a short time could cause the purge operation that flushes data from the buffer pool to stall. If this issue occurs, restart the server to work around it. This issue is only likely to occur on 32-bit platforms. 
- InnoDB: If the server crashed during a TRUNCATE TABLE or CREATE INDEX statement for an InnoDB table, or a DROP DATABASE statement for a database containing InnoDB tables, an index could be corrupted, causing an error message when accessing the table after restart:
- InnoDB: Error: trying to load index index_name for table table_name
- InnoDB: but the index tree has been freed!
In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in InnoDB storage engine. 
- InnoDB: When data was removed from an InnoDB table, newly inserted data might not reuse the freed disk blocks, leading to an unexpected size increase for the system tablespace or .ibd file (depending on the setting of innodb_file_per_table. The OPTIMIZE TABLE could compact a .ibd file in some cases but not others. The freed disk blocks would eventually be reused as additional data was inserted. 
- Partitioning: After updating a row of a partitioned table and selecting that row within the same transaction with the query cache enabled, then performing a ROLLBACK, the same result was returned by an identical SELECT issued in a new transaction. 
- Replication: The --relay-log-space-limit option was sometimes ignored.
More specifically, when the SQL thread went to sleep, it allowed the I/O thread to queue additional events in such a way that the relay log space limit was bypassed, and the number of events in the queue could grow well past the point where the relay logs needed to be rotated. Now in such cases, the SQL thread checks to see whether the I/O thread should rotate and provide the SQL thread a chance to purge the logs (thus freeing space).
Note that, when the SQL thread is in the middle of a transaction, it cannot purge the logs; it can only ask for more events until the transaction is complete. Once the transaction is finished, the SQL thread can immediately instruct the I/O thread to rotate. 
- Mishandling of NO_BACKSLASH_ESCAPES SQL mode within stored procedures on slave servers could cause replication failures. 
- If the system time was adjusted backward during query execution, the apparent execution time could be negative. But in some cases these queries would be written to the slow query log, with the negative execution time written as a large unsigned number. Now statements with apparent negative execution time are not written to the slow query log. 
- mysql_store_result() and mysql_use_result() are not for use with prepared statements and are not intended to be called following mysql_stmt_execute(), but failed to return an error when invoked that way in libmysqld. 
- SHOW statements treated stored procedure, stored function, and event names as case sensitive. 
- On Windows, mysqlslap crashed for attempts to connect using shared memory.

更新時間：2012-05-09
更新細節：

What's new in this version:

- Security Fix: Bug #64884 was fixed.
- InnoDB: Replication: When binary log statements were replayed on the slave, the Com_insert, Com_update, and Com_delete counters were incremented by BEGIN statements initiating transactions affecting InnoDB tables but not by COMMIT statements ending such transactions. This affected these statements whether they were replicated or they were run using mysqlbinlog. 
- If the --bind-address option was given a host name value and the host name resolved to more than one IP address, the server failed to start. For example, with --bind-address=localhost, if localhost resolved to both 127.0.0.1 and ::1, startup failed. Now the server prefers the IPv4 address in such cases. 
- mysql_store_result() and mysql_use_result() are not for use with prepared statements and are not intended to be called following mysql_stmt_execute(), but failed to return an error when invoked that way in libmysqld. 
- On Windows, mysqlslap crashed for attempts to connect using shared memory.

更新時間：2012-05-09
更新細節：

What's new in this version:

- Security Fix: Bug #64884 was fixed.
- InnoDB: Replication: When binary log statements were replayed on the slave, the Com_insert, Com_update, and Com_delete counters were incremented by BEGIN statements initiating transactions affecting InnoDB tables but not by COMMIT statements ending such transactions. This affected these statements whether they were replicated or they were run using mysqlbinlog. 
- If the --bind-address option was given a host name value and the host name resolved to more than one IP address, the server failed to start. For example, with --bind-address=localhost, if localhost resolved to both 127.0.0.1 and ::1, startup failed. Now the server prefers the IPv4 address in such cases. 
- mysql_store_result() and mysql_use_result() are not for use with prepared statements and are not intended to be called following mysql_stmt_execute(), but failed to return an error when invoked that way in libmysqld. 
- On Windows, mysqlslap crashed for attempts to connect using shared memory.

更新時間：2012-04-16
更新細節：

What's new in this version:

Functionality Added or Changed:
* The MySQL-shared-compat RPM package enables users of Red Hat-privided mysql-*-5.1 RPM packages to migrate to Oracle-provided MySQL-*-5.5 packages. MySQL-shared-compat now replaces the Red Hat mysql-libs package by replacing libmysqlclient.so files of the latter package, thus satisfying dependencies of other packages on mysql-libs. This change affects only users of Red Hat (or Red Hat-compatible) RPM packages. Nothing is different for users of Oracle RPM packages. 

Bugs Fixed:
* Security Fix: Bug #59533 was fixed.
* Performance: Partitioning: InnoDB Storage Engine: The statistics used by the optimizer for queries against partitioned InnoDB tables were based only on the first partition of each such table, leading to use of the wrong execution plan. 
* Performance: InnoDB Storage Engine: Improved the performance of the DROP TABLE statement for InnoDB tables, especially on systems with a large buffer pool. The fix speeds up the processing for freeing entries in the adaptive hash index. 
* InnoDB Storage Engine: Deleting a huge amount of data from InnoDB tables within a short time could cause the purge operation that flushes data from the buffer pool to stall. If this issue occurs, restart the server to work around it. This issue is only likely to occur on 32-bit platforms. 
* InnoDB Storage Engine: If the server crashed during a TRUNCATE TABLE or CREATE INDEX statement for an InnoDB table, or a DROP DATABASE statement for a database containing InnoDB tables, an index could be corrupted, causing an error message when accessing the table after restart:
- InnoDB: Error: trying to load index index_name for table table_name
- InnoDB: but the index tree has been freed!
In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in InnoDB storage engine. 
* InnoDB Storage Engine: When data was removed from an InnoDB table, newly inserted data might not reuse the freed disk blocks, leading to an unexpected size increase for the system tablespace or .ibd file (depending on the setting of innodb_file_per_table. The OPTIMIZE TABLE could compact a .ibd file in some cases but not others. The freed disk blocks would eventually be reused as additional data was inserted. 
* Partitioning: After updating a row of a partitioned table and selecting that row within the same transaction with the query cache enabled, then performing a ROLLBACK, the same result was returned by an identical SELECT issued in a new transaction. 
* Replication: Formerly, the default value shown for the Port column in the output of SHOW SLAVE HOSTS was 3306 whether the port had been set incorrectly or not set at all. Now, when the slave port is not set, 0 is used as the default. This change also affects the default used for the --report-port server option. 
* Replication: The --relay-log-space-limit option was sometimes ignored. More specifically, when the SQL thread went to sleep, it allowed the I/O thread to queue additional events in such a way that the relay log space limit was bypassed, and the number of events in the queue could grow well past the point where the relay logs needed to be rotated. Now in such cases, the SQL thread checks to see whether the I/O thread should rotate and provide the SQL thread a chance to purge the logs (thus freeing space). Note that, when the SQL thread is in the middle of a transaction, it cannot purge the logs; it can only ask for more events until the transaction is complete. Once the transaction is finished, the SQL thread can immediately instruct the I/O thread to rotate. 
* An infinite thread loop could develop within Performance Schema, causing the server to become unresponsive. 
* Incorrect stored program caching could cause statements within a stored program that included a GROUP BY clause to return different results across multiple program invocations.
* Mishandling of NO_BACKSLASH_ESCAPES SQL mode within stored procedures on slave servers could cause replication failures. 
* SAVEPOINT statements were incorrectly disallowed within XA transactions. 
* The Performance Schema incorrectly displayed some backslashes in Windows file names (by doubling them). 
* SHOW statements treated stored procedure, stored function, and event names as case sensitive.

更新時間：2012-04-16
更新細節：

What's new in this version:

Functionality Added or Changed:
* The MySQL-shared-compat RPM package enables users of Red Hat-privided mysql-*-5.1 RPM packages to migrate to Oracle-provided MySQL-*-5.5 packages. MySQL-shared-compat now replaces the Red Hat mysql-libs package by replacing libmysqlclient.so files of the latter package, thus satisfying dependencies of other packages on mysql-libs. This change affects only users of Red Hat (or Red Hat-compatible) RPM packages. Nothing is different for users of Oracle RPM packages. 

Bugs Fixed:
* Security Fix: Bug #59533 was fixed.
* Performance: Partitioning: InnoDB Storage Engine: The statistics used by the optimizer for queries against partitioned InnoDB tables were based only on the first partition of each such table, leading to use of the wrong execution plan. 
* Performance: InnoDB Storage Engine: Improved the performance of the DROP TABLE statement for InnoDB tables, especially on systems with a large buffer pool. The fix speeds up the processing for freeing entries in the adaptive hash index. 
* InnoDB Storage Engine: Deleting a huge amount of data from InnoDB tables within a short time could cause the purge operation that flushes data from the buffer pool to stall. If this issue occurs, restart the server to work around it. This issue is only likely to occur on 32-bit platforms. 
* InnoDB Storage Engine: If the server crashed during a TRUNCATE TABLE or CREATE INDEX statement for an InnoDB table, or a DROP DATABASE statement for a database containing InnoDB tables, an index could be corrupted, causing an error message when accessing the table after restart:
- InnoDB: Error: trying to load index index_name for table table_name
- InnoDB: but the index tree has been freed!
In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in InnoDB storage engine. 
* InnoDB Storage Engine: When data was removed from an InnoDB table, newly inserted data might not reuse the freed disk blocks, leading to an unexpected size increase for the system tablespace or .ibd file (depending on the setting of innodb_file_per_table. The OPTIMIZE TABLE could compact a .ibd file in some cases but not others. The freed disk blocks would eventually be reused as additional data was inserted. 
* Partitioning: After updating a row of a partitioned table and selecting that row within the same transaction with the query cache enabled, then performing a ROLLBACK, the same result was returned by an identical SELECT issued in a new transaction. 
* Replication: Formerly, the default value shown for the Port column in the output of SHOW SLAVE HOSTS was 3306 whether the port had been set incorrectly or not set at all. Now, when the slave port is not set, 0 is used as the default. This change also affects the default used for the --report-port server option. 
* Replication: The --relay-log-space-limit option was sometimes ignored. More specifically, when the SQL thread went to sleep, it allowed the I/O thread to queue additional events in such a way that the relay log space limit was bypassed, and the number of events in the queue could grow well past the point where the relay logs needed to be rotated. Now in such cases, the SQL thread checks to see whether the I/O thread should rotate and provide the SQL thread a chance to purge the logs (thus freeing space). Note that, when the SQL thread is in the middle of a transaction, it cannot purge the logs; it can only ask for more events until the transaction is complete. Once the transaction is finished, the SQL thread can immediately instruct the I/O thread to rotate. 
* An infinite thread loop could develop within Performance Schema, causing the server to become unresponsive. 
* Incorrect stored program caching could cause statements within a stored program that included a GROUP BY clause to return different results across multiple program invocations.
* Mishandling of NO_BACKSLASH_ESCAPES SQL mode within stored procedures on slave servers could cause replication failures. 
* SAVEPOINT statements were incorrectly disallowed within XA transactions. 
* The Performance Schema incorrectly displayed some backslashes in Windows file names (by doubling them). 
* SHOW statements treated stored procedure, stored function, and event names as case sensitive.