オリジナル版：http://dev.mysql.com/doc/refman/5.1/en/news-5-1-49.html
最も普及しているオープンソースデータベース管理システムの新バージョンMySQL Community Server 5.1.49がリリースされました。MySQL 5.1.49は、プロダクションシステムでの使用をお勧めします。
MySQL 5.1の新機能の概要については、以下を参照してください。
http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html
新たなサーバにMySQL 5.1.49をインストール、または以前のMySQLリリースからMySQL 5.1.49にアップグレードする際の情報については、以下を参照してください。
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-48.html
以下は、追加または変更された機能です。
* InnoDB Plugin has been upgraded to version 1.0.10. This
version is considered of General Availability (GA) quality.
InnoDB Plugin Change History
(http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-changes.
html), may contain information in addition to those changes
reported here.
In this release, the InnoDB Plugin is included in source and
binary distributions, except RHEL3, RHEL4, SuSE 9 (x86,
x86_64, ia64), and generic Linux RPM packages. It also does
not work for FreeBSD 6 and HP-UX or for Linux on generic ia64.
Bugs fixed:
* Replication: When using unique keys on NULL columns in
row-based replication, the slave sometimes chose the wrong row
when performing an update. This happened because a table
having a unique key on such a column could have multiple rows
containing NULL for the column used by the unique key, and the
slave merely picked the first row containing NULL in that
column. (Bug#53893: http://bugs.mysql.com/bug.php?id=53893)
* Replication: FLUSH LOGS could in some circumstances crash the
server. This occurred because the I/O thread could
concurrently access the relay log I/O cache while another
thread was performing the FLUSH LOGS, which closes and reopens
the relay log and, while doing so, initializes (or
re-initializes) its I/O cache. This could cause problems if
some other thread (in this case, the I/O thread) is accessing
it at the same time.
Now the thread performing the FLUSH LOGS takes a lock on the
relay log before actually flushing it.
(Bug#53657: http://bugs.mysql.com/bug.php?id=53657)
See also Bug#50364: http://bugs.mysql.com/bug.php?id=50364.
* Replication: Two related issues involving temporary tables and
transactions were introduced by a fix made in MySQL 5.1.37:
1. When a temporary table was created or dropped within a
transaction, any failed statement that following the
CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statement
triggered a rollback, which caused the slave diverge from
the master.
2. When a CREATE TEMPORARY TABLE ... SELECT * FROM ...
statement was executed within a transaction in which only
tables using transactional storage engines were used and
the transaction was rolled back at the end, the
changes---including the creation of the temporary
table---were not written to the binary log.
The current fix restores the correct behavior in both of these
cases. (Bug#53560: http://bugs.mysql.com/bug.php?id=53560)
This regression was introduced by
Bug#43929: http://bugs.mysql.com/bug.php?id=43929.
* Replication: When CURRENT_USER() or CURRENT_USER was used to
supply the name and host of the affected user or of the
definer in any of the statements DROP USER, RENAME USER,
GRANT, REVOKE, and ALTER EVENT, the reference to
CURRENT_USER() or CURRENT_USER was not expanded when written
to the binary log. This resulted in CURRENT_USER() or
CURRENT_USER being expanded to the user and host of the slave
SQL thread on the slave, thus breaking replication. Now
CURRENT_USER() and CURRENT_USER are expanded prior to being
written to the binary log in such cases, so that the correct
user and host are referenced on both the master and the slave.
(Bug#48321: http://bugs.mysql.com/bug.php?id=48321)
* An ALTER TABLE statement could convert an InnoDB compressed
table (with row_format=compressed) back to an uncompressed
table (with row_format=compact).
(Bug#54679: http://bugs.mysql.com/bug.php?id=54679)
* A signal-handler redefinition for SIGUSR1 was removed. The
redefinition could cause the server to encounter a kernel
deadlock on Solaris when there are many active threads. Other
POSIX platforms might also be affected.
(Bug#54667: http://bugs.mysql.com/bug.php?id=54667)
* InnoDB could issue an incorrect message on startup, if tables
were created under the setting innodb_file_per_table=ON and
the server was restarted under the setting
innodb_file_per_table=OFF. The message was of the form InnoDB:
Warning: allocated tablespace n, old maximum was 0.
(Bug#54658: http://bugs.mysql.com/bug.php?id=54658)
* The make_binary_distribution target to make could fail on some
platforms because the lines generated were too long for the
shell. (Bug#54590: http://bugs.mysql.com/bug.php?id=54590)
* The server failed to disregard sort order for some zero-length
tuples, leading to an assertion failure.
(Bug#54459: http://bugs.mysql.com/bug.php?id=54459)
* The default value of myisam_max_extra_sort_file_size
(http://dev.mysql.com/doc/refman/5.0/en/server-system-variable
s.html#sysvar_myisam_max_extra_sort_file_size) could be higher
than the maximum accepted value, leading to warnings upon the
server start.
(Bug#54457: http://bugs.mysql.com/bug.php?id=54457)
* If a session tried to drop a database containing a table
opened with HANDLER in another session, any DATABASE statement
(CREATE, DROP, ALTER) executed by that session produced a
deadlock. (Bug#54360: http://bugs.mysql.com/bug.php?id=54360)
* Fast index creation could fail, leaving the new secondary
index corrupted.
(Bug#54330: http://bugs.mysql.com/bug.php?id=54330)
* A client could supply data in chunks to a prepared statement
parameter other than of type TEXT or BLOB using the
mysql_stmt_send_long_data() C API function (or
COM_STMT_SEND_LONG_DATA command). This led to a crash because
other data types are not valid for long data.
(Bug#54041: http://bugs.mysql.com/bug.php?id=54041)
* Builds of the embedded mysqld would fail due to a missing
element of the struct NET.
(Bug#53908: http://bugs.mysql.com/bug.php?id=53908,
Bug#53912: http://bugs.mysql.com/bug.php?id=53912)
* The definition of the MY_INIT macro in my_sys.h included an
extraneous semicolon, which could cause compilation failure.
(Bug#53906: http://bugs.mysql.com/bug.php?id=53906)
* A client with automatic reconnection enabled saw the error
message Lost connection to MySQL server during query if the
connection was lost between the mysql_stmt_prepare() and
mysql_stmt_execute() C API functions. However,
mysql_stmt_errno() returned 0, not the corresponding error
number 2013.
(Bug#53899: http://bugs.mysql.com/bug.php?id=53899)
* Queries that used MIN() or MAX() on indexed columns could be
optimized incorrectly.
(Bug#53859: http://bugs.mysql.com/bug.php?id=53859)
* The Lock_time value in the slow query log was negative for
stored routines.
(Bug#53191: http://bugs.mysql.com/bug.php?id=53191)
* The results of some ORDER BY ... DESC queries were sorted
incorrectly.
(Bug#51431: http://bugs.mysql.com/bug.php?id=51431)
* Index Merge between three indexes could return incorrect
results. (Bug#50389: http://bugs.mysql.com/bug.php?id=50389)
* Performing large numbers of RENAME TABLE statements caused
excessive memory use.
(Bug#47991: http://bugs.mysql.com/bug.php?id=47991)
* The server could crash with an out of memory error when trying
to parse a query that was too long to fit in memory. Now the
parser rejects such queries with an ER_OUT_OF_RESOURCES error.
(Bug#42064: http://bugs.mysql.com/bug.php?id=42064)
* Sort-index_merge for join tables other than the first table
used excessive memory.
(Bug#41660: http://bugs.mysql.com/bug.php?id=41660)
* Valgrind warnings in the InnoDB compare_record() function were
corrected. (Bug#38999: http://bugs.mysql.com/bug.php?id=38999)
* mysqld could fail during execution when using SSL.
(Bug#34236: http://bugs.mysql.com/bug.php?id=34236)
* The behavior of the RPM upgrade installation has changed.
During an upgrade installation using the RPM packages, if the
MySQL server is running when the upgrade occurs, the server is
stopped, the upgrade occurs, and server is restarted. If the
server is not already running when the RPM upgrade occurs, the
server is not started at the end of the upgrade. The boot
scripts for MySQL are installed in the appropriate directories
in /etc, so the MySQL server will be restarted automatically
at the next machine reboot.
(Bug#27072: http://bugs.mysql.com/bug.php?id=27072)