機能の追加または変更 :

・ MySQLのディストリビューションに、INFO_SRCファイルが追加された。これは、作成元のMySQLのバージョンなど、ソースディストリビューションに関する情報を含むファイルである。MySQLのバイナリディストリビューションにはINFO_BINファイルが追加された。これは、コンパイラオプションや機能フラグなど、ディストリビューションのビルド方法に関する情報を含むファイルである。RPMパッケージの場合、これらのファイルは/usr/share/doc/packages/MySQL-serverディレクトリにある。tar.gzおよび派生パッケージの場合、ディストリビューションを圧縮解除した場所の下位のDocsディレクトリにある（Bug#42969、Bug#11751935）。

・ 以前は、クエリがソートの問題によって異常終了した、またはソートの途中で KILL によって終了した場合、サーバが Sortaborted というメッセージをエラーログに書き込んでいた。現在、サーバはエラーの原因についてさらに詳細な情報を書き出すようになっている。次のような原因がある。

otmpdirのディスク容量が不十分なため、tmpfileが作成されない。

osort_buffer_sizeに割り当てるメモリが不足している。

oファイルソートの途中でKILL id が実行された。

oクエリがソートを実行中にサーバがシャットダウンされた。

oロック待ちタイムアウトまたはデッドロックにより、トランザクションがロールバックされた、または異常終了した。

oソーステーブルまたはテンポラリテーブルが破損するなど予期しないエラーが発生した。同様にソートを実行していたサブクエリの処理が失敗した。

o

（Bug#30771、Bug#11747102）

§新しいシステム変数 max_long_data_size は現在、CAPI関数 mysql_stmt_send_long_data() で送信可能なパラメータ値の最大サイズを制御する。サーバ起動時に設定しない場合、デフォルトはシステム変数 max_allowed_packet の値である。この変数は非推奨となっており、MySQL5.6では削除され、最大パラメータサイズは max_allowed_packet によって制御されるようになっている。

§Windowsインストーラの場合は、大多数のユーザにとってダウンロードサイズが小さくなるように、デバッグ情報のファイルと埋め込みMySQLサーバが標準MSIディストリビューションファイルから削除されている。

これらのファイルが必要な場合には、ZIP形式のディストリビューションを別途ダウンロードし、インストールディレクトリに展開する必要がある。インストールディレクトリは、英語版システムではほとんどの場合C:\ProgramFiles\MySQL\MySQLServer5.5である。

製品をアンインストールする際、ZIP形式のディストリビューションから展開したファイルは手動でシステムから削除する必要がある。

§記載されていない SHOWNEWMASTER ステートメントは削除された。

修正されたバグ :

・ パーティショニング :パーティションの多いテーブルに対して INSERTONDUPLICATEKEYUPDATE ステートメントのパフォーマンスが低くなる点を以前に修正したが、その修正に問題があったため、特定のインデックスから行を読み込むハンドラ関数が、最後に使用されたパーティションのIDを格納できなかった。そのため、一部のステートメントが失敗しCan'tfindrecordエラーになっていた（Bug#59297、Bug#11766232）。

・ storage/ndb/test/sqlにある2つの未使用のテストファイルに、不正なバージョンのGNULesserGeneralPublicLicenseが含まれていた。それを含むファイルとディレクトリは削除されている（Bug#11810224）。

Bug#11810156も参照。

・ 大きい数値の除算でスタックが破損する可能性があった（Bug#11792200）。

・ レプリケーション : DROPDATABASE ステートメントに失敗すると、ステートメントベースのレプリケーションが中断することがあった（Bug#58381、Bug#11765416）。

・ mysql_load_client_plugin() CAPI関数が以前のエラーをクリアしなかった（Bug#60075、Bug#11766854）。

・ XAトランザクションで、トランザクションのロールバックを必要とするエラー（デッドロックなど）がすでに発生している場合に XACOMMIT が発生すると、表明が発生していた（Bug#59986、Bug#11766788）。

・ 一部のシステムで、初期化されていない変数のためにcomp_err.cのデバッグビルドが失敗する可能性があった（Bug#59906、Bug#11766729）。

・ UpdateXML() または ExtractValue() の引数として使用されている閉じの一重引用符（ ' ）文字または二重引用符（ " ）文字がないXML文字列を処理しようとしたとき、サーバが1バイト多く読み込んでいた（Bug#59901、Bug#11766725）。

Bug#44332、Bug#11752979も参照。

・ サーバがsafemutexサポートでコンパイルされていた場合、31バイトより長い CHAR カラムに空間インデックスを作成しようとすると表明違反になっていた（Bug#59888、Bug#11766714）。

・ 集計にサブクエリが続くと、結果が正しくならない可能性があった（Bug#59839、Bug#11766675）。

・以前は、バイナリログとリレーログのどちらでもパフォーマンススキーマのインストルメント機能には次のインストルメントを使用していた。

・wait/io/file/sql/binlog

・wait/io/file/sql/binlog_index

・wait/synch/mutex/sql/MYSQL_BIN_LOG::LOCK_index

・wait/synch/cond/sql/MYSQL_BIN_LOG::update_cond

現在、リレーログのインストルメント機能には以下のインストルメントが使用されるようになり、バイナリログのイベントとリレーログのイベントが区別できるようになっている。

wait/io/file/sql/relaylog

wait/io/file/sql/relaylog_index

wait/synch/mutex/sql/MYSQL_RELAY_LOG::LOCK_index

wait/synch/cond/sql/MYSQL_RELAY_LOG::update_cond

（Bug#59658、Bug#11766528）

・ 不正な文字セットポインタが my_strtoll10_mb2() に渡されると、表明が発生する可能性があった（Bug#59648、Bug#11766519）。

・ MySQL5.5における FIND_IN_SET() の動作が、5.1のときと異なる可能性があった（Bug#59405、Bug#11766317）。

・ mysqldump が、 ALTERDATABASE ステートメントでデータベース名に引用符を付けなかったため、データベース名にダッシュが含まれる場合の再ロード時にエラーが発生する可能性があった（Bug#59398、Bug#11766310）。

・ MYSQL_HOME 環境変数が無視されていた（Bug#59280、Bug#11766219）。

・ MySQLプログラムの --defaults-extra-file オプションで、パス名の引数が無効だったため、プログラムがクラッシュしていた（Bug#59234、Bug#11766184）。

・ Windowsで、 mysql.user テーブルに最近追加された authentication_string カラムが原因で構成ウィザードが失敗していた（Bug#59038、Bug#11766011）。

・ CREATETRIGGER と DROPTRIGGER は、ストアドルーチンのprelockingリストを変更するが、ルーチンキャッシュでその変更が検出されなかったため、ルーチンを実行するとロックリストが正しくならなかった（Bug#58674、Bug#11765684）。

・ PROCEDUREANALYSE() のコードに DBUG_RETURN ステートメントがなかったため、デバッグビルドでサーバがクラッシュする可能性があった（Bug#58140、Bug#11765202）。

・ アクティブな FLUSHTABLE tbl_list WITHREADLOCK ステートメントがあるとき、ステートメントでメタデータロックをアップグレードしようとすると、表明が発生していた。現在は、このような状況でステートメントがメタデータロックをアップグレードしようとすると、サーバからクライアントに ER_TABLE_NOT_LOCKED_FOR_WRITE エラーが返される（Bug#57649、Bug#11764779）。

・ マルチテーブル更新が2つのエイリアスを通じて行を更新する場合に、最初の更新で物理的に行が移動され、2番目の更新は行の検索に失敗していた。そのため、ストレージエンジンによって異なるエラーが発生したが、それらのエラーは問題を正確に表していなかった。

o MyISAM :Goterror134fromstorageengine

o InnoDB :Can'tfindrecordin'tbl'

MyISAMの場合は、非トランザクショナルであるため、最初に実行される更新は実行されるが2番目の更新は実行されなかった。また、同じマルチテーブル更新ステートメントが2つある場合、一方は成功するが、もう一方はレコードが実際に移動したかどうかによって失敗することがあり、矛盾が生じていた。

現在は、複数のエイリアスを通じてテーブルを更新し、少なくともそのエイリアスの一方で物理的に行が移動されるような更新を実行すると、エラーが返される（Bug#57373、Bug#11764529、Bug#55385、Bug#11762751）。

§ EXPLAINEXTENDED に続く SHOWWARNINGS 出力に、出力できない文字が含まれる可能性があった（Bug#57341、Bug#11764503）。

§以前のステートメントが失敗していると、 SHOWWARNINGS は空の結果を返す場合があった（Bug#55847、Bug#11763166）。

§Windowsで、スレッドローカルストレージのオブジェクトが、作成される前に使用される可能性があった（Bug#55730、Bug#11763065）。

§クライアントがSSLを使用して接続されている場合、 Ssl_cipher_list ステータス変数が空になり、想定される暗号タイプを示さなかった（Bug#52596、Bug#11760210）。

§ mysqlcheck （または、 mysqlcheck を呼び出す mysql_upgrade ）を使用してテーブルをアップグレードすると、テーブルの修復が必要と判定された一部のテーブルがアップグレードされなかった。具体的には、修復が必要な InnoDB テーブルのアップグレードに失敗するため、非アップグレードの状態になっていた。これは以下の原因で発生していた。

o mysqlcheck--check-upgrade---auto-repair が、現在のバージョンのMySQLと互換性のないテーブルをチェックする。 CHECKTABLE...FORUPGRADE ステートメントを発行し、結果を調べることによってそれが実行される。

o互換性がないと確認されたテーブルに対し、 mysqlcheck が REPAIRTABLE ステートメントを発行するが、 InnoDB のように修復操作をサポートしていないストレージエンジンでは、これが失敗する。その結果、テーブルが未変更のままになる。

この問題を修正するために、 CHECKTABLE...FORUPGRADE と mysqlcheck に以下の変更を加えた。 mysql_upgrade は mysqlcheck を呼び出すので、この変更で mysql_upgrade の問題も修正される。

oテーブルは修復を必要としているが、そのストレージエンジンが REPAIRTABLE をサポートしていない場合には、 CHECKTABLE...FORUPGRADE で返されるエラーを変更する。

以前:

Error: ER_TABLE_NEEDS_UPGRADE

Tableupgraderequired.Pleasedo"REPAIRTABLE` tbl_name `"or

dump/reloadtofixit!

現在:

Error: ER_TABLE_NEEDS_REBUILD

Tablerebuildrequired.Pleasedo"ALTERTABLE` tbl_name `FORCE"or

dump/reloadtofixit!

o mysqlcheck は新しいエラーを認識し、 ALTERTABLE...FORCE ステートメントを発行する。 ALTERTABLE の FORCE オプションは認識されるが何も実行していなかった。現在は実装が済み、NULL変更操作として動作するのでテーブルは再ビルドされる。

（Bug#47205、Bug#11755431）

§ CASE...WHEN 引数の文字セットが異なっている場合、8ビット値が utf16 値または utf32 値として参照され、表明が発生する可能性があった（Bug#44793、Bug#11753363）。

§1つのスレッドでビットマップ関数を使用すると、別のスレッドで使用されるビットマップが変更され、表明が発生する可能性があった（Bug#43152、Bug#11752069）。