オリジナル版：http://dev.mysql.com/doc/refman/5.1/en/news-5-1-65.html
最も普及しているオープンソースデータベース管理システムの新バージョンMySQL Community Server 5.1.65がリリースされました。MySQL 5.1.65は、プロダクションシステムでの使用をお勧めします。
注意: 5.1.64はリリースされませんので、5.1.63の次のバージョンはこの5.1.65となります。
MySQL 5.1の新機能の概要については、以下を参照してください。
http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html
新たなサーバにMySQL 5.1.65をインストール、または以前の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
以下は、追加または変更された機能です。
D.1.2. Changes in MySQL 5.1.65 (August 9, 2012)
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. For more information, see
Section 11.3.4, "YEAR(2) Limitations and Migrating to
YEAR(4)."
* Important Change: Replication: The SHOW BINARY LOGS statement
(and its equivalent SHOW MASTER LOGS) may now be executed by a
user with the REPLICATION CLIENT privilege. (Formerly, the
SUPER privilege was necessary to use either form of this
statement.)
Bugs Fixed
* The server did not build with gcc 4.7. (Bug #14238406)
* 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. (Bug #14100254, Bug #65389)
* 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 Consistent Nonlocking Reads
(http://dev.mysql.com/doc/refman/5.1/en/innodb-consistent-read
.html), DML statements within a REPEATABLE READ transaction
apply to rows committed by other transactions, even if a query
could not see those rows. (Bug #14007649, Bug #65111)
* 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
(Bug #13933132)
* 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. (Bug #12752572, Bug #61579)
* 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. (Bug #11758510, Bug
#50723)
* Replication: It was theoretically possible for concurrent
execution of more than one instance of SHOW BINLOG EVENTS to
crash the MySQL Server. (Bug #13979418)
* 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.
(Bug #12400221, Bug #60926)
* 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 (see How
Servers Evaluate Replication Filtering Rules
(http://dev.mysql.com/doc/refman/5.1/en/replication-rules.html
)). (Bug #11761686, Bug #54201)
References: See also Bug #11754117, Bug #45670, Bug #11746146,
Bug #23894.
* 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. For more information, see
Determination of Safe and Unsafe Statements in Binary Logging
(http://dev.mysql.com/doc/refman/5.1/en/replication-rbr-safe-u
nsafe.html), as well as Replication and AUTO_INCREMENT
(http://dev.mysql.com/doc/refman/5.1/en/replication-features-a
uto-increment.html).
Note
Tables using the InnoDB storage engine are not affected by
this issue, since InnoDB does not allow the creation of a
composite key that includes an AUTO_INCREMENT column, where
this column is not the first column in the key.
(Bug #11754117, Bug #45670)
References: See also Bug #11761686, Bug #54201, Bug #11746146,
Bug #23894.
* Replication: After upgrading a replication slave to MySQL
5.5.60 or later, enabling the query cache eventually caused
the slave to fail. (Bug #64624, Bug #14005409)
* 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. (Bug
#13805127)
* For queries with ORDER BY COUNT(*) and LIMIT, the optimizer
could choose an execution plan that produced incorrect
results. (Bug #12713907)
* SHOW TABLES was very slow unless the required information was
already in the disk cache. (Bug #60961, Bug #12427262)
* mysqlbinlog exited with no error code if file write errors
occurred. (Bug #55289, Bug #11762667)
* yaSSL rejected valid SSL certificates that OpenSSL accepts.
(Bug #54348, Bug #11761822)
* Sessions could end up deadlocked when executing a combination
of SELECT, DROP TABLE, KILL, and SHOW ENGINE INNODB STATUS.
(Bug #60682, Bug #12636001)