InnoDBに関する注意事項:

・ InnoDBPlugin は、バージョン1.0.10にアップグレードされている。本バージョンは、GeneralAvailability（GA）の品質であるとみなされている。

今回のリリースでは、 InnoDBPlugin は、RHEL3、RHEL4、SuSE9（x86、x86_64、ia64）、LinuxRPM汎用パッケージ、およびiccコンパイラで生成されたビルドを除き、ソースおよびバイナリディストリビューションに含まれている。また、FreeBSD6とHP-UX、およびia64全般のLinuxでは動作しない。

修正されたバグ:

・ セキュリティ修正 : innodb_file_format または innodb_file_per_table 構成パラメータの値を変更すると、DDLステートメントによってサーバがクラッシュする可能性があった（ Bug#55039 ）。

・ セキュリティ修正 : ユニーク SET カラム付きのテーブルを伴う結合は、サーバのクラッシュを引き起こす可能性があった（ Bug#54575 ）。

・ セキュリティ修正 : IN() または CASE 演算で、NULL引数が明示的に引数として渡されるか（ IN() の場合）、 WITHROLLUP 修飾子によって暗黙的に生成されると（ IN() および CASE の場合）、 NULL 引数の不正な処理によってクラッシュが発生する可能性があった（ Bug#54477 ）。

・ セキュリティ修正 : BINLOG ステートメントに不正な引数を使用すると、 Valgrind警告またはサーバのクラッシュが発生する可能性があった（ Bug#54393 ）。

・ セキュリティ修正 :NULL 可能なカラムがあるテンポラリ InnoDB テーブルを使用すると、サーバがクラッシュする可能性があった（ Bug#54044 ）。

・ セキュリティ修正 : HANDLER インタフェースを使用してテーブルの 2 つのインデックスから交互に読み取りを行うと、サーバがクラッシュする可能性があった（ Bug#54007 ）。

・ セキュリティ修正 : SELECT...UNION...ORDERBY(SELECT...WHERE...) という形式のクエリで EXPLAIN を使用すると、サーバがクラッシュする可能性があった（ Bug#52711 ）。

・ セキュリティ修正 : LOADDATAINFILE は SQLエラーをチェックせず、エラーがすでにレポートされていてもOKパケットを送信した。また、デバッグサーバでは、クライアントサーバプロトコルのチェックに関連する表明が、発生すべきでないときに発生することがあった（ Bug#52512 ）。

・ レプリケーション : 行ベースのレプリケーションで NULL カラムのユニークキーを使用した場合、スレーブは更新の実行時に間違った行を選択することがあった。そのようなカラムにユニークキーがあるテーブルは、ユニークキーによって使用されるカラムに対して NULL を含む複数の行を持つ可能性があり、スレーブはそのカラムに NULL が含まれている最初の行を単に選択したため、この問題が発生した（ Bug#53893 ）。

・ レプリケーション : FLUSHLOGS は、環境によってはサーバをクラッシュさせる可能性があった。 I/O スレッドは別のスレッドが FLUSHLOGS を実行しているときにリレーログI/Oキャッシュに同時にアクセスできたため、この問題が発生した。 FLUSHLOGS は、リレーログを閉じて再度開きながらI/Oキャッシュを初期化（または再初期化）する。この問題により、他のスレッド（この場合はI/Oスレッド）がI/Oキャッシュに同時にアクセスしている場合は問題が発生する可能性があった。

現在、 FLUSHLOGS を実行するスレッドは、リレーログを実際にフラッシュする前にリレーログのロックを取得するようになっている（ Bug#53657 ）。

Bug#50364 も参照。

・ レプリケーション : MySQL5.1.37 で行われた修正により、テンポラリテーブルとトランザクションに関わる 2 つの関連する問題がもたらされた。

1.トランザクション内でテンポラリテーブルを作成または削除すると、 CREATETEMPORARYTABLE または DROPTEMPORARYTABLE ステートメントの後の失敗したステートメントは後退復帰をトリガした。これにより、スレーブがマスタから分化された。

2.トランザクショナルストレージエンジンを使用しているテーブルだけが使用されるトランザクション内で CREATETEMPORARYTABLE...SELECT*FROM... ステートメントが実行され、そのトランザクションが最後に後退復帰された場合、変更内容（テンポラリテーブルの作成を含む）はバイナリログに書き込まれなかった。

現在の修正では、上記の両方のケースで正しい動作が復元される（ Bug#53560 ）。

この退化は、 Bug#43929 によってもたらされた。

・ レプリケーション : CURRENT_USER() または CURRENT_USER を使用して、影響を受けるユーザまたは定義者の名前とホストを DROPUSER 、 RENAMEUSER 、 GRANT 、 REVOKE 、または ALTEREVENT ステートメントで指定した場合、 CURRENT_USER() または CURRENT_USER の参照は、バイナリログへの書き込み時に展開されなかった。その結果、 CURRENT_USER() または CURRENT_USER はスレーブ上のスレーブSQLスレッドのユーザとホストに展開されたため、レプリケーションは中断された。現在、そのようなケースでは、 CURRENT_USER() および CURRENT_USER はバイナリログに書き込まれる前に展開されるため、マスタとスレーブの両方で正しいユーザとホストが参照されるようになっている（ Bug#48321 ）。

・ ALTERTABLE ステートメントは、 InnoDB 圧縮テーブル（ row_format=compressed ）を元の未圧縮のテーブル（ row_format=compact ）に変換する可能性があった（ Bug#54679 ）。

・ SIGUSR1 のシグナルハンドラ再定義は削除された。アクティブなスレッドが数多く存在する場合、この再定義を使用すると、Solaris上のサーバでカーネルデッドロックが発生する可能性があった。場合によっては、他のPOSIXプラットフォームも影響を受けることがあった（ Bug#54667 ）。

・ innodb_file_per_table=ON の設定のもとでテーブルが作成され、 innodb_file_per_table=OFF の設定のもとでサーバが再起動された場合、 InnoDB は起動時に不正なメッセージを発行する可能性があった。そのメッセージは、 InnoDB:Warning:allocatedtablespace n ,oldmaximumwas0 という形式だった（ Bug#54658 ）。

・ make の make_binary_distribution ターゲットは、生成される行がシェルにとって長すぎたため、一部のプラットフォームで失敗する可能性があった（ Bug#54590 ）。

・サーバが長さゼロのいくつかのタプルのソート順序を無視しなかったため、表明違反が発生した（ Bug#54459 ）。

・ myisam_max_extra_sort_file_size のデフォルト値が最大許容値よりも高くなり、その結果、サーバ起動時に警告が表示される可能性があった（ Bug#54457 ）。

・ SHOW ステートメントと INFORMATION_SCHEMA クエリ間の関係の一貫性のないチェックにより、 INFORMATION_SCHEMA クエリが失敗することがあった（ Bug#54422 ）。

・セッションが、別のセッション内の HANDLER で開かれたテーブルを含むデータベースを削除しようとした場合、そのセッションによって実行された DATABASE ステートメント（ CREATE 、 DROP 、 ALTER ）はデッドロックを生成した（ Bug#54360 ）。

・高速インデックス作成が失敗し、新しいセカンダリインデックスが壊れたままになる可能性があった（ Bug#54330 ）。

・ structNET の要素が欠けていたため、 埋め込み mysqld のビルドが失敗した（ Bug#53908 、 Bug#53912 ）。

・ my_sys.h 内の MY_INIT マクロの定義には無関係なセミコロンが含まれていたため、コンパイルが失敗する可能性があった（ Bug#53906 ）。

・CAPI関数の mysql_stmt_prepare() と mysql_stmt_execute() の間で接続が失われた場合、自動再接続が有効になっているクライアントには LostconnectiontoMySQLserverduringquery というエラーメッセージが表示された。ただし、 mysql_stmt_errno() は、対応するエラー番号2013ではなく0を返した（ Bug#53899 ）。

・インデックス付きカラムで MIN() または MAX() を使用するクエリは、正しく最適化されない可能性があった（ Bug#53859 ）。

・ SELECT および SELECTFORUPDATE ステートメントの組み合わせの中には、ロックに関するエラーを発生して失敗したり、 半一貫的な読み取り 操作中に行ロックを不正に解放したりするものがあった（ Bug#53674 ）。

・ストアドルーチンの場合、スロークエリログの Lock_time 値は負の値だった（ Bug#53191 ）。

・一部の ORDERBY...DESC クエリの結果は、正しくソートされなかった（ Bug#51431 ）。

・ 3 つのインデックス間のインデックスマージは、不正な結果を返す可能性があった（ Bug#50389 ）。

・数多くの RENAMETABLE ステートメントを実行すると、メモリが過剰に使用された（ Bug#47991 ）。

・サーバは、長すぎてメモリに収まらないクエリの解析時にメモリ不足エラーでクラッシュする可能性があった。現在、パーサは、そのようなクエリを拒否して ER_OUT_OF_RESOURCES エラーを発生するようになっている（ Bug#42064 ）。

・最初のテーブル以外の結合テーブルに対するSort- index_merge は、過剰にメモリを使用した（ Bug#41660 ）。

・REDOログのスペースが十分にあるかどうかをチェックするメカニズムが改良され、 ERROR:theageofthelastcheckpointis x ,whichexceedstheloggroupcapacity y というメッセージが発生する可能性が減少した（ Bug#39168 ）。

・ InnoDB compare_record() 関数におけるValgrind警告が修正された（ Bug#38999 ）。

・SSLを使用した場合、 mysqld は実行中に失敗する可能性があった（ Bug#34236 ）。

・RPMアップグレードインストールの動作が変更されている。RPMパッケージを使用したアップグレードインストールでは、アップグレードが行われるときにMySQLサーバが動作している場合、サーバが停止され、アップグレードが行われて、サーバが再起動される。RPMアップグレードが行われるときにサーバがまだ動作していない場合は、アップグレードの終了時にサーバは起動されない。MySQLのブートスクリプトは /etc 内の該当ディレクトリにインストールされるため、MySQLサーバは次回のマシン再起動時に自動的に再起動される（ Bug#27072 ）。