MySQL Community Server 5.1.68 がリリースされました


最も普及しているオープンソースデータベース管理システムの新バージョンMySQL Community Server 5.1.68がリリースされました。MySQL 5.1.68は、プロダクションシステムでの使用をお勧めします。

MySQL 5.1の新機能の概要については、以下を参照してください。


新たなサーバにMySQL 5.1.68をインストール、または以前のMySQLリリースからMySQL 5.1.61にアップグレードする際の情報については、以下を参照してください。







MySQL 5.1に関するオープンな問題の情報については、以下のエラッタリストを参照してください。





Changes in MySQL 5.1.68 (5 February, 2013)

Bugs Fixed

  * Performance: InnoDB: Optimized read operations for compressed
    pression) tables by skipping redundant tests. The check for
    whether any related changes needed to be merged from the
    insert buffer
    ert_buffer) was being called more often than necessary. (Bug
    #14329288, Bug #65886)

  * Performance: InnoDB: Immediately after a table was created,
    queries against it would not use loose index scans
    html#loose-index-scan). The issue went away following an ALTER
    TABLE on the table. The fix improves the accuracy of the index
    ex_statistics) gathered when the table is first created. (Bug

  * Partitioning: InnoDB: Previously, when attempting to optimize
    one or more partitions of a partitioned table that used a
    storage engine that does not support partition-level OPTIMIZE,
    such as InnoDB, MySQL reported Table does not support
    optimize, doing recreate + analyze instead, then re-created
    the entire table, but did not actually analyze it. Now in such
    cases, the warning message is, Table does not support optimize
    on partitions. All partitions will be rebuilt and analyzed. In
    addition, the entire table is analyzed after first being
    rebuilt. (Bug #11751825)

  * InnoDB: The status variable
    Innodb_buffer_pool_read_ahead_evicted could show an inaccurate
    value, higher than expected, because some pages in the buffer
    fer_pool) were incorrectly considered as being brought in by
    d_ahead) requests. (Bug #15859402, Bug #67476)

  * InnoDB: Creating an index on a CHAR column could fail for a
    table with a character set with varying length, such as UTF-8,
    if the table was created with the ROW_FORMAT=REDUNDANT clause.
    (Bug #15874001)

  * InnoDB: If the server crashed at a precise moment during an
    ALTER TABLE operation that rebuilt the clustered index
    stered_index) for an InnoDB table, the original table could be
    inaccessible afterward. An example of such an operation is
    ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original
    table if the server halts during this operation. You might
    still need to rename the .ibd file manually to restore the
    original table contents: in MySQL 5.6 and higher, rename from
    #sql-ib$new_table_id.ibd to table_name.ibd within the database
    directory; prior to MySQL 5.6, the temporary file to rename is
    table_name#1 or #2. (Bug #14669848)

  * InnoDB: An error at the filesystem level, such as too many
    open files, could cause an unhandled error during an ALTER
    TABLE operation. The error could be accompanied by Valgrind
    warnings, and by this assertion message:
    Assertion `! is_set()' failed.
    mysqld got signal 6 ;
    (Bug #14628410, Bug #16000909)

  * InnoDB: During shutdown, with the innodb_purge_threads
    configuration option set greater than 1, the server could halt
    prematurely with this error:
    mysqld got signal 11
    A workaround was to increase innodb_log_file_size and set
    innodb_purge_threads=1. The fix was backported to MySQL 5.5
    and 5.1, although those versions do not have the
    innodb_purge_threads configuration option so the error was
    unlikely to occur. (Bug #14234028)

  * InnoDB: The value of the innodb_version variable was not
    updated consistently for all server releases for the InnoDB
    Plugin in MySQL 5.1, and the integrated InnoDB component in
    MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server
    development cycles are fully integrated and synchronized, now
    the value returned by the innodb_version variable is the same
    as for the version variable. (Bug #13463493, Bug #63435)

  * Partitioning: When used with a table having multiple columns
    in its primary key, but partitioned by KEY using a column that
    was not part of the primary key as the partitioning column, a
    query using an aggregate function and DISTINCT such as SELECT
    SUM(DISTINCT pk_column_1) FROM table WHERE pk_column_2 =
    constant was not handled correctly. (Bug #14845133)
    References: See also Bug #14495351. This bug was introduced by
    Bug #13025132.

  * Replication: Repeated execution of CHANGE MASTER TO statements
    using invalid MASTER_LOG_POS values could lead to errors and
    possibly a crash on the slave. Now in such cases, the
    statement fails with a clear error message. (Bug #11764602,
    Bug #57454)

  * Replication: If the disk becomes full while writing to the
    binary log, the server hangs until space is freed up manually.
    It was possible after was done for the MySQL server to fail,
    due to an internal status value being set when not needed. Now
    in such cases, rather than trying to set this status, a
    warning is written in the error log instead. (Bug #11753923,
    Bug #45449)

  * Microsoft Windows: Dynamic file names (with colons) are no
    longer allowed. Static file names using the Alternate Data
    Stream (ADS) NTFS functionality of Microsoft Windows may
    continue to be used. (Bug #11761752)

  * It was possible in theory for UpdateXML() to return NULL
    incorrectly. (Bug #15948580)
    References: See also Bug #13007062.

  * For MEMORY tables with HASH indexes, DELETE sometimes failed
    to delete all applicable rows. (Bug #51763, Bug #11759445)