MySQL5.5.30 での変更点（ 2013-02-05 ）

このリリースで判明している制限:

MicrosoftWindowsで、異なるバージョン（5.6.10など）およびライセンス（コミュニティに対するコマーシャル）が付与された既存のMySQLServerが搭載されたホストに、MySQLInstallerを使用してMySQLServer5.5.30をインストールする場合、まず既存のMySQLServerのライセンスタイプを更新する必要がある。これを行わない場合、MySQLInstallerは、MySQLServer5.5.30で選択したMySQLServerとライセンスが異なるものを削除する。

MicrosoftWindows8では、コミュニティリリースをコマーシャルリリースに更新する際、更新後にMySQLサービスを手動で再起動する必要がある。

機能の追加と変更

・ InnoDB: 圧縮テーブルを使用した場合、圧縮されたページが16KBまたはユーザ指定した ページサイズ よりも小さい可能性があるため、 バッファプール 内でのメモリ使用量の計算が複雑であった。この情報は INFORMATION_SCHEMA.INNODB_BUFFER_PAGE テーブルから検索できるものの、その操作は非効率的である。以下の新しいステータス変数により、バッファプールのメモリ使用量に関する計算が容易になる。

　　・ Innodb_buffer_pool_bytes_data （ Innodb_buffer_pool_pages_data を補足）

　　・ Innodb_buffer_pool_bytes_dirty （ Innodb_buffer_pool_pages_dirty を補足）

（Bug#15842637）

・ InnoDB: MySQL5.6の innodb_print_all_deadlocks 構成オプションがMySQL5.5にバックポートされた。このオプションでは各 デッドロック 状態がMySQLエラーログに記録されるため、デッドロックによるアプリケーションのコーディング問題が頻繁に指摘される場合のトラブルシューティングがより簡単になる（Bug#14515889）。

・ UnbreakableLinuxNetwork用に構築されたRPMパッケージでは、libmysqld.soはバージョン番号が付与されるようになった（Bug#15972480）。

修正されたバグ

・ InnoDB; パフォーマンス : ログの取り消しに関連する一部のデータ構造が、たとえ特定の条件下でのみ必要とされる場合であっても、クエリ中に不必要に初期化される可能性があった（Bug#14676084）。

・ InnoDB; パフォーマンス : 冗長なテストをスキップすることにより、 圧縮 テーブルに対する読み取り操作が最適化された。関連する変更を 挿入バッファ からマージする必要があるかどうかのチェックが必要以上に呼び出されていた（Bug#14329288、Bug#65886）。

・ InnoDB; パフォーマンス : 作成したばかりのテーブルにクエリを実行した場合、 ルースインデックススキャン が使用されなかった。テーブル上で ALTERTABLE を実行した後はこの問題は解消されていた。修正では、テーブルを最初に作成したときに収集される インデックス統計 の精度を向上し、クエリプランが ALTERTABLE ステートメントによって変更されないようにした（Bug#14200010）。

・ InnoDB; パーティショニング : これまで、パーティションレベルの OPTIMIZE をサポートしていない InnoDB などのストレージエンジンを使用するパーティションドテーブルの1つ以上のパーティションを最適化しようとすると、MySQLはTable does not support optimize, doing recreate + analyzeinsteadをレポートした後、テーブル全体を作成し直したが、実際には解析が行われていなかった。現在、このような場合、警告メッセージはTable does not support optimizeonpartitions. All partitions will be rebuilt and analyzedである。加えて、まずパーティションの再構築後、テーブル全体が解析される（Bug#11751825）。

・ InnoDB: 未整列メモリアクセスを処理できないシステムでは、スタックフレームのアラインメントに応じて、起動時に SIGBUS エラーが発生する可能性があった。この問題はSolaris64ビットシステムで検出された（Bug#16021177）。

・ InnoDB: バッファプール のいくつかのページが 先読み 要求によって取り込まれたものと間違って認識されたために、ステータス変数 Innodb_buffer_pool_read_ahead_evicted が、予想よりも高い、不正確な値を示す可能性があった（Bug#15859402、Bug#67476）。

・ InnoDB: 文字セットが UTF-8 など可変長であるテーブルに対して CHAR カラムにインデックスを作成する場合、 ROW_FORMAT=REDUNDANT 句でこのテーブルが作成されていると、失敗する可能性があった（Bug#15874001）。

・ InnoDB: インデックスの作成中に、表明エラーが発生し、サーバが中断する可能性があった。

　　InnoDB: Assertion failure in thread thread_num in file row0merge.cc line 465

この問題は、 ROW_FORMAT=REDUNDANT オフページカラム と カラムプリフィックス のインデックスの組み合わせを持つテーブルに影響した（Bug#14753402）。

・ InnoDB: ALTERTABLE 操作時に、 InnoDB テーブルに対して クラスタ化されたインデックス をちょうど再構築しているときにサーバがクラッシュした場合、それ以降オリジナルのテーブルにアクセスできなくなる可能性があった。このような操作の例は ALTERTABLE...ADDPRIMARYKEY である。修正では、この操作中にサーバが中断した場合、オリジナルのテーブルを保持する。ただし、オリジナルのテーブルの内容をリストアするために、手動で .ibd ファイル名を変更する必要がある。MySQL5.6以降では#sql-ib$ new_table_id .ibdをデータベースディレクトリ内で table_name .ibdに変更し、MySQL5.6よりも以前でファイル名を変更するテンポラリファイルは table_name #1または#2である（Bug#14669848）。

・ InnoDB: 開いているファイルが多すぎるなど、ファイルシステムレベルのエラーにより、 ALTERTABLE 操作時に未処理のエラーが発生する可能性があった。このエラーはValgrind警告、および次の表明メッセージを伴う可能性があった。

　　Assertion `! is_set()' failed.
　　mysqld got signal 6 ;

（Bug#14628410、Bug#16000909）

・ InnoDB: RENAMETABLE ステートメントがタイムアウトする前に数分間ストールする可能性があった。この問題は、 変更バッファリング が有効になっている状態で、 圧縮 を使用するテーブルで発生する可能性があった（Bug#14556349）。

・ InnoDB: シャットダウン時に、 innodb_purge_threads 構成オプションが1よりも大きい値に設定されていると、以下のエラーが発生し、サーバが途中で中断する可能性があった。

mysqld got signal 11

回避策は、 innodb_log_file_size を大きくし、 innodb_purge_threads=1 を設定することであった。 innodb_purge_threads 構成オプションがないため、エラーが発生する可能性は低かったが、MySQL5.5および5.1に修正がバックポートされた（Bug#14234028）。

・ InnoDB: innodb_force_recovery の値が6未満の場合、破損したテーブルを開く際に、そのテーブルの統計の計算時に破損ページが読み込まれた場合、無限ループが発生する可能性があった。破損ページに関する情報がエラーログに何度も書き込まれ、場合によってはディスクスペースの問題を招いた。修正により、ページの読み取りが一定回数失敗すると、サーバが中断する。このような破損問題を解決するには、 innodb_force_recovery=6 を設定し、再起動する（Bug#14147491、Bug#65469）。

・ InnoDB: MySQL5.1のInnoDBプラグインの全サーバリリース、およびMySQL5.5、5.6、それ以降の統合 InnoDB コンポーネントに対する innodb_version 変数の値の更新に一貫性がなかった。 InnoDB とMySQLServerの開発サイクルが完全に統合化され、同期化されたため、現在 innodb_version 変数で返される値は version 変数と同じである（Bug#13463493、Bug#63435）。

・ パーティショニング : 同時実行の ALTERTABLE...REBUILDPARTITION 操作が、たとえ同じテーブルに対して実行していなくても、どちらもストレージとしてグローバルメモリを使用しているために、互いに干渉する可能性があった。現在では、各パーティションの再構築操作で、そのプロセスにローカルなメモリに中間データを格納するようになった（Bug#14589559、Bug#66645）。

・ パーティショニング : 1000を超えるパーティションを使用する ARCHIVE テーブルに任意の数の行を挿入後、このテーブルをドロップしようとすると、MySQLServerが失敗した（Bug#13819630、Bug#64580）。

・ レプリケーション : スレーブバージョンのテーブルからカラムをドロップし、マスタ上でこのテーブルの同じカラムを修正した後（スレーブでカラムがドロップされていなければ、型変換が必要となるため）、このテーブルへ挿入を行うと、レプリケーションが失敗した（Bug#15888454）。

・ レプリケーション : バイナリログをサーバで再実行した場合（たとえば、 mysqlbinlog binlog.000001 | mysql のようなコマンドを実行するなど）、サーバがbinlogを読み取り、バイナリログイベントを正しく適用できるように、使用するクライアント接続で疑似スレーブモードが設定される。ただし、バイナリログダンプの読み取り後も疑似スレーブモードが無効にならず、同じ接続で引き続き実行されるSQLステートメントに予期しないフィルタリングルールが適用されていた（Bug#15891524）。

・ レプリケーション : ステートメントベースのレプリケーションを使用し、 AUTO_INCREMENT カラムが異なるテーブルスキーマをマスタとスレーブが使用している場合、マスタの特定のテーブルに対してログが記録される AUTO_INCREMENT 値を生成する挿入がスレーブの間違ったテーブルに適用される可能性があった（Bug#12669186）。

・ レプリケーション : 無効な MASTER_LOG_POS 値を使用して CHANGEMASTERTO ステートメントを何度も実行すると、エラーが生じ、場合によってはスレーブでクラッシュが発生する可能性があった。現在、このような場合、ステートメントが失敗し、明確なエラーメッセージが表示されるBug#11764602、Bug#57454）

・ レプリケーション : バイナリログへの書き込み中にディスクがいっぱいになった場合、スペースを手動で解放するまで、サーバがハングする。この後、必要でないときに内部ステータス値が設定されるために、MySQLサーバが失敗する可能性があった。現在、このような場合、このステータスを設定する代わりに、エラーログに警告が書き込まれる（Bug#11753923、Bug#45449）。

・ MicrosoftWindows: ダイナミックなファイル名（コロンを使用）は許可されなくなった。MicrosoftWindowsのADS（AlternateDataStream:代替データストリーム）NTFS機能を使用するスタティックなファイル名は引き続き使用できる（Bug#11761752）。

・ MacOSXおよびWindows上でディレクトリ名処理により、スタックオーバーフローが発生する可能性があった（Bug#16066243）。

・ テーブル数が32ちょうどで、 HAVING 句を伴う結合では、空の結果が返されていた（Bug#15972635）。

・ yaSSLのバッファ処理問題が修正された（Bug#15965288）。

・ mysys ライブラリの文字列書式設定ルーチンが幅指定子の処理を誤る可能性があった（Bug#15960005）。

・ 場合によって、 UpdateXML() が間違って NULL を返す可能性があった（Bug#15948580）。

参考:Bug#13007062も参照。

・ メタデータロックおよびテーブル定義のキャッシュルーチンが、受け渡された名前の長さを必ずしもチェックしなかった（Bug#15954872）。

・ XASTART が競合状態になり、サーバがクラッシュする可能性があった（Bug#14729757）。

・ クライアント競合が高い間にクエリキャッシュを有効にすると、サーバが終了する可能性があった（Bug#14727815）。

・ SELECT...INTO ユーザ変数および INTO リストの変数の1つ以上で WHERE 条件を使用したクエリの場合、パフォーマンスが低下していた（Bug#14664077）。

参考:このバグはBug#12408412で紹介された。

・ サーバがユーザ接続で MAX_CONNECTIONS_PER_HOUR 限度を守らないことがあった（Bug#14627287）。

・ mysqldump--routines で生成された出力を再ロードすると、構文エラーが生成される可能性があった（Bug#14463669）。

・ スレッドプールプラグインがインストールされている場合、同時実行の KILL ステートメントとpingクエリから構成される作業負荷により、サーバが終了した（Bug#14458232、Bug#14458002）。

・ MyISAM テーブルに破損したキー（ .MYI ）ファイルがある場合、 CHECKTABLE および REPAIRTABLE がクラッシュする可能性があった。現在はサーバでエラーが生成される（Bug#13556107、Bug#13556000）。

・ 不明な時間帯指定を CONVERT_TZ() に受け渡すと、メモリリークが発生した（Bug#12347040）。

・ mysql データベースのダンプについて、--eventsオプションが指定されない限り、 mysqldump は event テーブルをスキップしていた。必要な場合にこのテーブルをスキップするには、代わりに--ignore-tableオプションを使用する（Bug#55587、Bug#11762933）。

・ HASH インデックス付きの MEMORY テーブルに対して、 DELETE が該当するすべての行を削除できないことがあった（Bug#51763、Bug#11759445）。

・ mysql が引用符付き文字列の終わりを検索している行で delimiter コマンドが実行された場合、 mysql クライアントが処理を誤る可能性があった（Bug#64135、Bug#13639125）。

・ mysqld_safe で移植不能な -e テスト構造を使用していた（Bug#67976、Bug#16046140）。

・ performance_schema_events_waits_history_size=0 および performance_schema_events_waits_history_long_size=0 でサーバを構成すると、パフォーマンススキーマのセグメンテーションエラーが発生する可能性があった（Bug#68008、Bug#16060864）。

・ DECIMAL 乗算操作でかなりの誤差を生じる可能性があった（Bug#45860、Bug#11754279）。

・ ファイルソート を使用して実行するサブクエリに対して、オプティマイザが間違った行を含む不正確な結果を生成する可能性があった（Bug#66845、Bug#14636211）。

参考:Bug#12667154も参照。

・ UNION 型変換で、符号なし値を符号付き値に間違って変換する可能性があった（Bug#49003、Bug#11757005）。

・ 起動プロセス中、 mysqld がすでに実行している mysqld のPIDファイルを間違って削除する可能性があった（Bug#23790、Bug#11746142）。

参考:Bug#14726272も参照。