MySQL 5.5.25a がリリースされました


MySQL 5.5.25aは世界でもっともポピュラーなオープンソースデータベースの5.5のプロダクトリリースの新しいバージョンです。MySQL 5.5.25aはプロダクションシステムでの使用をお勧めします。

MySQL 5.5.25aはオプティマイザ内に検出されたリグレッションバグを持つMySQL 5.5.25の代替です。このバグのため、5.5.25はダウンロードサイトより削除されました。MySQL 5.5.25をインストールしているユーザは早い機会にMySQL 5.5.25aへアップグレードすることをお勧めしいます。このバグはMySQL 5.5.25固有のもので、それ以外のバージョンには影響ありません。

MySQL 5.5は最新のマルチCPUやマルチコアハードウェアやオペレーティングシステムの利点を生かし、MySQLデータベースのパフォーマンスとスケーラビリ ティを改善するための影響の大きい変更をいくつか含んでいます。現在ではInnoDBがMySQLデータベースのデフォルトのストレージエンジンであり、 ACIDトランザクション、参照整合性、クラッシュリカバリをデフォルトで提供しています。

MySQL 5.5は以下の多くの新しい強化も含んでいます:

   - Windowsにおける特有の機能と改善を利用した著しいパフォーマンス向上
   - 新しい準同期レプリケーションとレプリケーションハートビートによるより高いレベルの可用性
   - 改善されたインデックスとテーブルパーティショニング、SIGNAL/RESIGNALサポート、そして新しいPERFORMANCE_SCHEMAに含まれる強化された診断法による改善されたユーザビリティ

MySQL 5.5の新機能のより完全な概観については、以下のリソースを参照下さい。

MySQL 5.5 GA、Tomas Ulinのインタビュー:




ホワイトペーパー: MySQL 5.5の新機能


製品レベルのシステムでMySQLを稼動させているならば、MySQL製品、バックアップ、モニタリング、モデリング、開発、管理ツールの包括的なセット を含むMySQLパフォーマンス、セキュリティ、アップタイムの高いレベルを実現するMySQL Enterprise Editionの製品詳細に注目してください。


新しいサーバへMySQL 5.5.25をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。





MySQL Server 5.5は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。




次の節では、MySQL 5.5の以前のバージョンからのMySQLソースコードの変更を記載しています。これはオンラインでも閲覧できます。

D.1.2. Changes in MySQL 5.5.25a (2012-July-05)


Due to MSI restrictions, the MSI packages of MySQL 5.5.25a will
treat the version as 5.5.26 internally; for example, as displayed
by the Installation Wizard. MySQL itself reports the version as
5.5.25a; for example, if you check the value of the VERSION() SQL
function or the version system variable.

Bugs Fixed

* A regression bug in the optimizer could cause excessive disk
usage for UPDATE statements. (Bug #65745, Bug #14248833)
D.1.2. Changes in MySQL 5.5.25 (2012-May-30)

Functionality Added or Changed

  * The --safe-mode server option now is deprecated and will be
    removed in MySQL 5.6.

Bugs Fixed

  * Performance: InnoDB: Improved the algorithm related to
    adaptive flushing. This fix increases the rate of flushing in
    cases where compression is used and the data set is larger
    than the buffer pool, leading to eviction. (Bug #13990648, Bug

  * 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 Section, "Consistent
    Nonlocking Reads," 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

  * InnoDB: The Innodb_buffer_pool_pages_flushed status variable
    was incorrectly set to twice the value it should be. Its value
    should never exceed the value of Innodb_pages_written. (Bug
    #14000361, Bug #65030)

  * InnoDB: The error handling and message was improved for
    attempting to create a foreign key with a column referencing
    itself. The message suggested a potential problem with the
    data dictionary, when no such problem existed. (Bug #12902967)

  * 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

  * 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: 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
    Section 16.2.3, "How Servers Evaluate Replication Filtering
    Rules"). (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
    Section, "Determination of Safe and Unsafe Statements
    in Binary Logging," as well as Section, "Replication
    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.

  * SHOW TABLES was very slow unless the required information was
    already in the disk cache. (Bug #60961, Bug #12427262)