オリジナル版：http://dev.mysql.com/doc/refman/5.1/en/news-5-1-62.html
最も普及しているオープンソースデータベース管理システムの新バージョンMySQL Community Server 5.1.62がリリースされました。MySQL 5.1.62は、プロダクションシステムでの使用をお勧めします。
MySQL 5.1の新機能の概要については、以下を参照してください。
http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html
新たなサーバにMySQL 5.1.62をインストール、または以前の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-62.html
以下は、追加または変更された機能です。
D.1.1. Changes in MySQL 5.1.62 (21 March, 2012)
Functionality Added or Changed
* yaSSL was upgraded from version 1.7.2 to 2.2.0.
Bugs Fixed
* Security Fix: Bug #13510739 and Bug #63775 were fixed.
* Incompatible Change: An earlier change (in MySQL 5.1.59 and
5.5.16) was found to modify date-handling behavior in General
Availability-status series (MySQL 5.1 and 5.5). This change
has been reverted.
The change was that several functions became more strict when
passed a DATE() function value as their argument, thus they
rejected incomplete dates with a day part of zero. These
functions were affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(),
DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(),
TO_SECONDS()
(http://dev.mysql.com/doc/refman/5.5/en/date-and-time-function
s.html#function_to-seconds), WEEK(), WEEKDAY(), WEEKOFYEAR(),
YEARWEEK(). The previous behavior has been restored. (Bug
#13458237)
* Important Change: InnoDB Storage Engine: When a row grew in
size due to an UPDATE operation, other (non-updated) columns
could be moved to off-page storage so that information about
the row still fit within the constraints of the InnoDB page
size. The pointer to the new allocated off-page data was not
set up until the pages were allocated and written, potentially
leading to lost data if the system crashed while the column
was being moved out of the page. The problem was more common
with tables using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED
along with the Barracuda file format, particularly with the
innodb_file_per_table setting enabled, because page allocation
operations are more common as the .ibd tablespace files are
extended. Still, the problem could occur with any combination
of InnoDB version, file format, and row format.
A related issue was that during such an UPDATE operation, or
an INSERT operation that reused a delete-marked record, other
transactions could see invalid data for the affected column,
regardless of isolation level.
The fix corrects the order of operations for moving the column
data off the original page and replacing it with a pointer.
Now if a crash occurs at the precise moment when the column
data is being transferred, the transfer will not be re-run
during crash recovery.
In MySQL 5.1, this fix applies to the InnoDB Plugin, but not
the built-in InnoDB storage engine. (Bug #13721257, Bug
#12612184, Bug #12704861)
* InnoDB Storage Engine: An erroneous assertion could occur, in
debug builds only, when creating an index on a column
containing zero-length values (that is, ''). (Bug #13654923)
* InnoDB Storage Engine: A DDL operation such as ALTER TABLE ...
ADD COLUMN could stall, eventually timing out with an Error
1005: Can't create table message referring to
fil_rename_tablespace. (Bug #13636122, Bug #62100, Bug #63553)
* InnoDB Storage Engine: References to C preprocessor symbols
and macros HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and
UNIV_SET_MEM_TO_ZERO were removed from the InnoDB source code.
They were only used in debug builds instrumented for Valgrind.
They are replaced by calls to the UNIV_MEM_INVALID() macro.
(Bug #13418934)
* InnoDB Storage Engine: A DDL operation for an InnoDB table
could cause a busy MySQL server to halt with an assertion
error:
InnoDB: Failing assertion: trx->error_state == DB_SUCCESS
The error occurred if the DDL operation was run while all 1023
undo slots were in use by concurrent transactions. This error
was less likely to occur in MySQL 5.5 and 5.6, because raising
the number of InnoDB undo slots increased the number of
simultaneous transactions (corresponding to the number of undo
slots) from 1K to 128K. (Bug #12739098, Bug #62401)
* InnoDB Storage Engine: With 1024 concurrent InnoDB
transactions running concurrently and the
innodb_file_per_table setting enabled, a CREATE TABLE
operation for an InnoDB table could fail. The .ibd file from
the failed CREATE TABLE was left behind, preventing the table
from being created later, after the load had dropped.
The fix adds error handling to delete the erroneous .ibd file.
This error was less likely to occur in MySQL 5.5 and 5.6,
because raising the number of InnoDB undo slots increased the
number of simultaneous transactions needed to trigger the bug,
from 1K to 128K. (Bug #12400341)
* InnoDB Storage Engine: When copying a partitioned InnoDB table
from a Linux system to a Windows system, you could encounter
this error:
101115 14:19:53 [ERROR] Table .\test\d has no primary key in InnoDB d
ata
dictionary, but has one in MySQL!
Normally, the solution to copy InnoDB tables from Linux to
Windows is to create the tables on Linux with the
lower_case_table_names option enabled. Partitioned tables,
with #P# appended to the filename, were not covered by that
solution. (Bug #11765438, Bug #58406)
* InnoDB Storage Engine: Server startup could produce an error
for temporary tables using the InnoDB storage engine, if the
path in the $TMPDIR variable ended with a / character. The
error log would look like:
120202 19:21:26 InnoDB: Operating system error number 2 in a file op
eration.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
120202 19:21:26 InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file './t/#sql7750_1_0.ibd'!
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: It is also possible that this is a temporary table #sql...,
InnoDB: and MySQL removed the .ibd file for this.
The workaround for the problem was to create a similar
temporary table again, copy its .frm file to tmpdir under the
name mentioned in the error message (for example, #sql123.frm)
and restart mysqld with tmpdir set to its normal value without
a trailing slash, for example /var/tmp. On startup, MySQL
would see the .frm file and issue DROP TABLE for the orphaned
temporary table. (Bug #11754376, Bug #45976)
* A query that used an index on a CHAR column referenced in a
BETWEEN clause could return invalid results. (Bug #13463488,
Bug #63437)
* When the optimizer performed conversion of DECIMAL values
while evaluating range conditions, it could produce incorrect
results. (Bug #13453382)
* When used with the --xml option, mysqldump --routines failed
to dump any stored routines, triggers, or events. (Bug
#11760384, Bug #52792)
* It was possible on replication slaves where FEDERATED tables
were in use to get timeouts on long-running operations, such
as Error 1160 Got an error writing communication packets. The
FEDERATED tables did not need to be replicated for the issue
to occur. (Bug #11758931, Bug #51196)
References: See also Bug #12896628, Bug #61790.
* If an attempt to initiate a statement failed, the issue could
not be reported to the client because it was not prepared to
receive any error messages prior to the execution of any
statement. Since the user could not execute any queries, they
were simply disconnected without providing a clear error.
After the fix for this issue, the client is prepared for an
error as soon as it attempts to initiate a statement, so that
the error can be reported prior to disconnecting the user.
(Bug #11755281, Bug #47032)
* Using myisamchk with the sort recover method to repair a table
having fixed-width row format could cause the row pointer size
to be reduced, effectively resulting in a smaller maximum data
file size. (Bug #48848, Bug #11756869)
* Due to improper locking, concurrent inserts into an ARCHIVE
table at the same time as repair and check operations on the
table resulted in table corruption. (Bug #37280, Bug
#11748748)