オリジナル版： http://dev.mysql.com/doc/refman/5.1/en/news-5-1-25.html
最も普及しているオープンソースデータベースの新たなリリース候補であるMySQL 5.1.25rc版がリリースされました。
MySQL 5.1.25rc版はまだ安定版候補のリリースであり、他の多くの試作商品リリースと同様、商品レベルのシステムまたは、重要なデータを含むシステムに対してインストールしないように注意してください。5.0使用の商品レベルのシステムについては、以下のMySQL Enterpriseの商品説明のページをご覧ください。
http://mysql.com/products/enterprise/
MySQL 5.1.25rc版は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。
すべてのミラーサイトが現在、最新であるとは限らないことに注意してください。
あるミラーサイトでこのバージョンを見つけることができない場合は、再度確認を行うか、あるいは別のダウンロード・サイトを選択してください。
さらに、私たちのミラーサイトのいくつかが破損ファイルを提供しているかもしれないという問題が現在あることにご注意ください。この問題解決のためにミラーサイトの管理者と共に努力しています。
バグレポート、バグ修正、パッチ等の情報をお待ちしておりますので、以下のページをご利用ください。
http://forge.mysql.com/wiki/Contributing
以下のセクションはMySQL5.1の最も最近にリリースされたバージョンであるMySQL5.1.24rc版と比較してのMySQLソースコードにおけるバージョン間の変更を記載しています。
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-25.html
以下は、追加または変更された機能です。
News from the ChangeLog:
Functionality added or changed:
* Incompatible Change: A change has been made to the way that
the server handles prepared statements. This affects prepared
statements processed at the SQL level (using the PREPARE
statement) and those processed using the binary client-server
protocol (using the mysql_stmt_prepare() C API function).
Previously, changes to metadata of tables or views referred to
in a prepared statement could cause a server crash when the
statement was next executed, or perhaps an error at execute
time with a crash occurring later. For example, this could
happen after dropping a table and recreating it with a
different definition.
Now metadata changes to tables or views referred to by
prepared statements are detected and cause automatic
repreparation of the statement when it is next executed.
Metadata changes occur for DDL statements such as those that
create, drop, alter, rename, or truncate tables, or that
analyze, optimize, or repair tables. Repreparation also occurs
after referenced tables or views are flushed from the table
definition cache, either implicitly to make room for new
entries in the cache, or explicitly due to FLUSH TABLES.
Repreparation is automatic, but to the extent that it occurs,
performance of prepared statements is diminished.
Table content changes (for example, with INSERT or UPDATE) do
not cause repreparation, nor do SELECT statements.
An incompatibility with previous versions of MySQL is that a
prepared statement may now return a different set of columns
or different column types from one execution to the next. For
example, if the prepared statement is SELECT * FROM t1,
altering t1 to contain a different number of columns causes
the next execution to return a number of columns different
from the previous execution.
Older versions of the client library cannot handle this change
in behavior. For applications that use prepared statements
with the new server, an upgrade to the new client library is
strongly recommended.
Along with this change to statement repreparation, the default
value of the table_definition_cache system variable has been
increased from 128 to 256. The purpose of this increase is to
lessen the chance that prepared statements will need
repreparation due to referred-to tables/views having been
flushed from the cache to make room for new entries.
A new status variable, Com_stmt_reprepare, has been introduced
to track the number of repreparations.
(Bug#27420: http://bugs.mysql.com/27420,
Bug#27430: http://bugs.mysql.com/27430,
Bug#27690: http://bugs.mysql.com/27690)
* Important Change: Some changes were made to CHECK TABLE ...
FOR UPGRADE and REPAIR TABLE with respect to detection and
handling of tables with incompatible .frm files (files created
with a different version of the MySQL server). These changes
also affect mysqlcheck because that program uses CHECK TABLE
and REPAIR table, and thus also mysql_upgrade because that
program invokes mysqlcheck.
+ If your table was created by a different version of the
MySQL server than the one you are currently running,
CHECK TABLE ... FOR UPGRADE indicates that the table has
an .frm file with an incompatible version. In this case,
the result set returned by CHECK TABLE contains a line
with a Msg_type value of error and a Msg_text value of
Table upgrade required. Please do "REPAIR TABLE
`tbl_name`" to fix it!
+ REPAIR TABLE without USE_FRM upgrades the .frm file to
the current version.
+ If you use REPAIR TABLE ...USE_FRM and your table was
created by a different version of the MySQL server than
the one you are currently running, REPAIR TABLE will not
attempt to repair the table. In this case, the result set
returned by REPAIR TABLE contains a line with a Msg_type
value of error and a Msg_text value of Failed repairing
incompatible .FRM file.
Previously, use of REPAIR TABLE ...USE_FRM with a table
created by a different version of the MySQL server risked
the loss of all rows in the table.
(Bug#36055: http://bugs.mysql.com/36055)
* mysql_upgrade now has a --tmpdir option to enable the location
of temporary files to be specified.
(Bug#36469: http://bugs.mysql.com/36469)
Bugs fixed:
* Important Change: The server no longer issues warnings for
truncation of excess spaces for values inserted into CHAR
columns. This reverts a change in the previous release that
caused warnings to be issued.
(Bug#30059: http://bugs.mysql.com/30059)
* Replication: CREATE PROCEDURE and CREATE FUNCTION statements
containing extended comments were not written to the binary
log correctly, causing parse errors on the slave.
(Bug#36570: http://bugs.mysql.com/36570)
See also Bug#32575: http://bugs.mysql.com/32575
* Replication: When flushing tables, there were a slight chance
that the flush occurred between the processing of one table
map event and the next. Since the tables were opened one by
one, subsequent locking of tables would cause the slave to
crash. This problem was observed when replicating NDBCLUSTER
or InnoDB tables, when executing multi-table updates, and when
a trigger or a stored routine performed an (additional) insert
on a table so that two tables were effectively being inserted
into in the same statement.
(Bug#36197: http://bugs.mysql.com/36197)
* Replication: CREATE VIEW statements containing extended
comments were not written to the binary log correctly, causing
parse errors on the slave. Now, all comments are stripped from
such statements before being written to the binary log.
(Bug#32575: http://bugs.mysql.com/32575)
See also Bug#36570: http://bugs.mysql.com/36570
* On WIndows 64-bit systems, temporary variables of long types
were used to store ulong values, causing key cache
initialization to receive distorted parameters. The effect was
that setting key_buffer_size to values of 2GB or more caused
memory exhaustion to due allocation of too much memory.
(Bug#36705: http://bugs.mysql.com/36705)
* Multiple-table UPDATE statements that used a temporary table
could fail to update all qualifying rows or fail with a
spurious duplicate-key error.
(Bug#36676: http://bugs.mysql.com/36676)
* A REGEXP match could return incorrect rows when the previous
row matched the expression and used CONCAT() with an empty
string. (Bug#36488: http://bugs.mysql.com/36488)
* mysqltest ignored the value of --tmpdir in one place.
(Bug#36465: http://bugs.mysql.com/36465)
* When updating an existing instance (for example, from MySQL
5.0 to 5.1, or 5.1 to 6.0), the Instance Configuration Wizard
unnecessarily prompted for a root password when there was an
existing root password.
(Bug#36305: http://bugs.mysql.com/36305)
* Conversion of a FLOAT ZEROFILL value to string could cause a
server crash if the value was NULL.
(Bug#36139: http://bugs.mysql.com/36139)
* On Windows, the installer attempted to use JScript to
determine whether the target data directory already existed.
On Windows Vista x64, this resulted in an error because the
installer was attempting to run the JScript in a 32-bit
engine, which wasn't registered on Vista. The installer no
longer uses JScript but instead relies on a native WiX
command. (Bug#36103: http://bugs.mysql.com/36103)
* mysqltest was performing escape processing for the
--replace_result command, which it should not have been.
(Bug#36041: http://bugs.mysql.com/36041)
* An error in calculation of the precision of zero-length items
(such as NULL) caused a server crash for queries that employed
temporary tables. (Bug#36023: http://bugs.mysql.com/36023)
* For EXPLAIN EXTENDED, execution of an uncorrelated IN subquery
caused a crash if the subquery required a temporary table for
its execution. (Bug#36011: http://bugs.mysql.com/36011)
* The MERGE storage engine did a table scan for SELECT COUNT(*)
statements when it could calculate the number of records from
the underlying tables.
(Bug#36006: http://bugs.mysql.com/36006)
* The server crashed inside NOT IN subqueries with an impossible
WHERE or HAVING clause, such as NOT IN (SELECT ... FROM t1,
t2, ... WHERE 0). (Bug#36005: http://bugs.mysql.com/36005)
* The Event Scheduler was not designed to work under the
embedded server. It is now disabled for the embedded server,
and the event_scheduler system variable is not displayed.
(Bug#35997: http://bugs.mysql.com/35997)
* Grouping or ordering of long values in unindexed BLOB or TEXT
columns with the gbk or big5 character set crashed the server.
(Bug#35993: http://bugs.mysql.com/35993)
* SET GLOBAL debug='' resulted in a Valgrind warning in
DbugParse(), which was reading beyond the end of the control
string. (Bug#35986: http://bugs.mysql.com/35986)
* The "prefer full scan on clustered primary key over full scan
of any secondary key" optimizer rule introduced by
Bug#26447: http://bugs.mysql.com/26447 caused a performance
regression for some queries, so it has been disabled.
(Bug#35850: http://bugs.mysql.com/35850)
* The server ignored any covering index used for ref access of a
table in a query with ORDER BY if this index was incompatible
with the ORDER BY list and there was another covering index
compatible with this list. As a result, suboptimal execution
plans were chosen for some queries that used an ORDER BY
clause. (Bug#35844: http://bugs.mysql.com/35844)
* mysql_upgrade did not properly update the mysql.event table.
(Bug#35824: http://bugs.mysql.com/35824)
* An incorrect error and message was produced for attempts to
create a MyISAM table with an index (.MYI) filename that was
already in use by some other MyISAM table that was open at the
same time. For example, this might happen if you use the same
value of the INDEX DIRECTORY table option for tables belonging
to different databases.
(Bug#35733: http://bugs.mysql.com/35733)
* Enabling the read_only system variable while autocommit mode
was enabled caused SELECT statements for transactional storage
engines to fail. (Bug#35732: http://bugs.mysql.com/35732)
* The combination of GROUP_CONCAT(), DISTINCT, and LEFT JOIN
could crash the server when the right table is empty.
(Bug#35298: http://bugs.mysql.com/35298)
* Some binaries produced stack corruption messages due to being
built with versions of bison older than 2.1. Builds are now
created using bison 2.3.
(Bug#34926: http://bugs.mysql.com/34926)
* On Windows 64-bit builds, an apparent compiler bug caused
memory overruns for code in innobase/mem/*. Removed
optimizations so as not to trigger this problem.
(Bug#34297: http://bugs.mysql.com/34297)
* Several additional configuration scripts in the BUILD
directory now are included in source distributions. These may
be useful for users who wish to build MySQL from source. (See
Section 2.9.3, "Installing from the Development Source Tree,"
for information about what they do.)
(Bug#34291: http://bugs.mysql.com/34291)
* Executing a FLUSH PRIVILEGES statement after creating a
temporary table in the mysql database with the same name as
one of the MySQL system tables caused the server to crash.
Note: While it is possible to shadow a system table in this
way, the temporary table exists only for the current user
and connection, and does not effect any user privileges.
(Bug#33275: http://bugs.mysql.com/33275)
* Assignment of relative pathnames to general_log_file or
slow_query_log_file did not always work.
(Bug#32748: http://bugs.mysql.com/32748)
* The mysql.servers table was not created during installation on
Windows. (Bug#28680: http://bugs.mysql.com/28680,
Bug#32797: http://bugs.mysql.com/32797)
* The jp test suite was not working.
(Bug#28563: http://bugs.mysql.com/28563)
* The internal init_time() library function was renamed to
my_init_time() to avoid conflicts with external libraries.
(Bug#26294: http://bugs.mysql.com/26294)
* The parser used signed rather than unsigned values in some
cases that caused legal lengths in column declarations to be
rejected. (Bug#15776: http://bugs.mysql.com/15776)