オリジナル版:http://dev.mysql.com/doc/refman/5.1/en/news-5-1-67.html
最も普及しているオープンソースデータベース管理システムの新バージョンMySQL Community Server 5.1.67がリリースされました。MySQL 5.1.67は、プロダクションシステムでの使用をお勧めします。
MySQL 5.1の新機能の概要については、以下を参照してください。
http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html
新たなサーバにMySQL 5.1.67をインストール、または以前のMySQLリリースからMySQL 5.1.61にアップグレードする際の情報については、以下を参照してください。
http://dev.mysql.com/doc/refman/5.1/en/installing.html
下記のダウンロードページから、MySQLサーバのソースコード及び多数のプラットフォーム用バイナリが入手可能です
http://dev.mysql.com/downloads/
現時点ですべてのミラーサイトが最新であるとは限らないことに注意してください。
あるミラーサイトで本バージョンを見つけることができない場合は、後日再確認を行うか、別のダウンロード・サイトを選択してください。
フィードバック、バグレポート、バグ修正、パッチ等の情報をお待ちしておりますので、以下のページをご利用ください。
http://forge.mysql.com/wiki/Contributing
MySQL 5.1に関するオープンな問題の情報については、以下のエラッタリストを参照してください。
http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html
以下のセクションは、MySQL5.1の前リリース以降のMySQLソースコードの変更を記載しています。これはオンラインでも閲覧可能です:
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-65.html
以下は、追加または変更された機能です。
A.1.1. Changes in MySQL 5.1.67 (Not yet released) 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 (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_ssd ). This enhancement primarily affects read operations for BLOB columns in compressed (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_com pression) tables. (Bug #13702112, Bug #64258) * 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. (Bug #14729221) * InnoDB: If a CREATE TABLE statement failed due to a disk full error, some memory allocated during the operation was not freed properly. (Bug #14708715) * InnoDB: If the server crashed at the specific point when a change buffer (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_cha nge_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 (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_ins ert_buffering) mechanism was generalized to cover other operations. (Bug #14636528, Bug #66819, Bug #58571, Bug #61104, Bug #65443) * InnoDB: In rare circumstances, MySQL could apply InnoDB undo (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_und o) records out of order during a ROLLBACK (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_rol lback) of an operation that modified a BLOB column. This issue could cause an assertion error in debug builds: !bpage->file_page_was_freed (Bug #13249921) * Replication: Updates writing user variables whose values were never set on a slave while using --replicate-ignore-table could cause the slave to fail. (Bug #14597605) References: This bug was introduced by Bug #14275000. * Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave. (Bug #14548159) * 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. (Bug #11750014) * Very long database names in queries could cause the server to exit. (Bug #15912213) * Within a stored procedure, executing a multiple-table DELETE statement that used a very long table alias could cause the server to exit. (Bug #15954896) * Attempting to create an auto-increment (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_aut o_increment) column in an InnoDB table with a NULL type attribute could cause a serious error. (Bug #14758479) * 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. (Bug #14731482) * Repeated execution of a query containing a subquery that used MAX() could result in increasing memory consumption. (Bug #14683676) * USE dbname could fail with Unknown database when dbname contained multiple backtick (`) characters. (Bug #14645196) * SHOW PROFILE could be used to cause excessive server memory consumption. (Bug #14629232) * 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). (Bug #14621627) * CREATE USER and DROP USER could fail to flush the privileges, requiring FLUSH PRIVILEGES to be used explicitly. (Bug #13864642) * A memory leak could occur for queries containing a subquery that used GROUP BY on an outer column. (Bug #13724099) * 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. (Bug #11753779) References: See also Bug #38247, Bug #43006, Bug #45584, Bug #45606. * 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. (Bug #57135, Bug #11764313) * On Windows, the Perl version of mysql_install_db created system tables in the mysql database that were not populated properly. (Bug #65584, Bug #14181049) * 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. (Bug #57406, Bug #11764559) * LAST_INSERT_ID(expr) did not work for expr values greater than the largest signed BIGINT value. (Bug #20964, Bug #11745891)