オリジナル版：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)