機能の追加と変更

・ 重要な変更 : YEAR(2) データタイプは問題があるため非推奨となる。 YEAR(2) のサポートは今後リリースされるMySQLで削除される。詳細については、 11.3.4項「YEAR(2)LimitationsandMigratingtoYEAR(4)」 を参照。

・ 平文のクライアント認証プラグイン mysql_clear_password は、クライアント側で入力されたパスワードをハッシュ化せずにそのままサーバで受け取ることを要求する認証方式に使用される。パスワードは平文で送信されるため、ネットワーク上でパスワードが漏えいしないように、このプラグインはSSL接続など安全な接続のコンテキストで使用する必要がある。このプラグインの不注意な使い方を避けるために、現在はクライアントで明示的な有効化が必要になった。有効にする方法は複数ある。

o LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN 環境変数を 1 、 Y 、または y で始まる値に設定する。この方法ではすべてのクライアント接続のプラグインが有効になる。

o mysql 、 mysqladmin 、 mysqlslap の各クライアントプログラムでは、起動ごとにプラグインを有効にする--enable-cleartext-pluginオプションがサポートされる。

oCAPI関数の mysql_options() では、接続ごとにプラグインを有効にする MYSQL_ENABLE_CLEARTEXT_PLUGIN オプションがサポートされる。また、 libmysqlclient を使用してオプションファイルを読み込むプログラムであれば、クライアントライブラリによって読み込まれるオプショングループに enable-cleartext-plugin オプションを追加してプラグインを有効にできる。

修正されたバグ

・ InnoDB :競合状態により、 InnoDB テーブルに対する DROPTABLE ステートメント中で表明エラーが発生する可能性があった。 InnoDB の内部関数には、テーブルスペースが欠落しているかどうかを正しく判定しないものや、テーブルスペースが欠落している場合にエラーコードを正しく処理しないものがあった（Bug#14251529）。

・ InnoDB : InnoDB テーブルから行が削除され、同じプライマリキー値を持つ別の行が再挿入された場合に、待機しなければならない同時トランザクションが行のロックを試行して成功する可能性があった。この問題は、ロックする側のSELECTで WHERE 句が使用され、セカンダリインデックスを使用してインデックススキャンが実行される場合に発生していた（Bug#14100254、Bug#65389）。

・ InnoDB : DROPDATABASE によるデータベースの削除中に ALTERTABLE... RENAME を使用して InnoDB テーブルを他のデータベースに移動した場合に、表明が発生する可能性があった（Bug#13982017）。

・ InnoDB : KILL ステートメントを使用してクエリを終了すると、エラーログで以下のような不要なメッセージが出力される可能性があった。

・[ERROR]Goterror-1whenreadingtabletable_name

（Bug#13933132）

・ InnoDB :トリガがある InnoDB テーブルで innodb_autoinc_lock_mode=1 が設定されている場合、2つのセッションから同時にテーブルへの挿入が実行されると自動増分値の間隔が空いてしまう可能性があった。自動増分値の並び方がタイミングによって異なるため、レプリケーションを使用するシステムでデータが不整合になった（Bug#12752572、Bug#61579）。

・ パーティショニング :パーティションドテーブルに範囲外の値を挿入すると、常に正しく処理されなかった。これは、MySQL5.5.23で発生した退化であった（Bug#14005441、Bug#65587）。

・ レプリケーション :イベントがマスタダンプスレッドの max_allowed_packet のサイズより長いと、レプリケーションが失敗した。これは、多数の大きい行を更新するときと、行ベースのレプリケーションを使用するときに発生する可能性があった。

この修正の一環として新しいサーバオプション --slave-max-allowed-packet が追加され、スレーブSQLとI/Oのスレッドでmax_allowed_packetのサイズ大きくできるようになる。現在、マスタからスレーブに送信されるパケットのサイズはこの値（サーバシステム変数 slave_max_allowed_packet の値として使用できる）に対してのみチェックされ、 max_allowed_packet の値に対してはチェックされなくなっている（Bug#12400221、Bug#60926）。

・ レプリケーション : UPDATE... WHERE primary_key_column = constant LIMIT1 などのステートメントは、実際には安全であるにもかかわらず、ステートメントベースログに対してアンセーフというフラグが設定される。このようなステートメントが大量に実行されると、この誤った警告が多数ログに記録されるためにディスクスペースが使い果たされる可能性があった。この事態を回避するために、警告抑止のメカニズムが導入されている。この警告抑止は以下のように動作する。最近50件の ER_BINLOG_UNSAFE_STATEMENT 警告が、50秒間に50回より多く生成されると、警告抑止が有効になる。警告抑止が有効になると、この警告はエラーログに書き込まれなくなり、かわりにこのタイプの警告50件ごとに、 Thelastwarningwasrepeated N timesinlast S seconds という注記がエラーログに書き込まれる。最近50件のこの警告が50秒以内に発生している限りこの動作が続き、警告がこのしきい値を下回った時点で警告はまた通常どおりに記録されるようになる。

この問題の修正によって、これらの警告がMySQLクライアントに報告される状態は変わらず、警告を生成するステートメントごとに警告は引き続きクライアントに送信される。この修正で、ステートメントベースログのステートメントの安全性を決定する方法も変わらない（Bug#11759333、Bug#51638）。

参考:Bug#11751521、Bug#42415も参照。

・ レプリケーション :レプリケーションスレーブをMySQL5.5.18以降にアップグレードした後で、クエリキャッシュを有効にすると、スレーブでエラーが発生した（Bug#64624、Bug#14005409）。

・ gcc 4.7でサーバがビルドされなかった（Bug#14238406）。

・ RPAD() の特定の引数でuninitializedvariable警告が発生する可能性があった（Bug#14039955）。

・ test データベースに.emptyという名前のファイルがあるため、このデータベースを削除できなかった（Bug#12845091）。

・プライマリ以外のインデックスに対するレンジスキャンを使用して実行する必要があり、ファイルソートを使用しなければならない複数のサブクエリで、最初のサブクエリしかレンジスキャンとして実行されなかった。それ以降のサブクエリはフルテーブルスキャンとして実行され、パフォーマンスが低下していた（Bug#12667154）。

・ サーバによってカウントされる特定ホストからの接続エラーの数は定期的にリセットされ、 max_connect_errors に達することがなかったため、無効なホストが接続を試行してもブロックされなかった（Bug#11753779）。

参考:Bug#38247、Bug#43006、Bug#45584、Bug#45606も参照。

・ ARCHIVE ストレージエンジンによるファイルアクセスが実装されていなかったため、パフォーマンススキーマテーブルに表示されなかった（Bug#63340、Bug#13417440）。

・ アカウントにゼロでない MAX_USER_CONNECTIONS 値がある場合、その値が優先されないことがあった（Bug#65104、Bug#14003080）。

・ ファイル書き込みエラーが発生した場合に、 mysqlbinlog がエラーコードなしで終了した（Bug#55289、Bug#11762667）。

・ CONCAT() を使用して LIKE パターンマッチのパターンを作成すると、メモリが破損しマッチングが失敗する可能性があった（Bug#59140、Bug#11766101）。

・OpenSSLで受け付けられる有効なSSL証明書をyaSSLが拒否していた（Bug#54348、Bug#11761822）

・ SELECT 、 DROPTABLE 、 KILL 、 SHOWENGINEINNODBSTATUS の組み合わせを実行すると、セッションがデッドロック状態で終了する可能性があった（Bug#60682、Bug#12636001）。

・ mysqldump は、ダンプファイルを再ロードするとエラーが発生するような順序で、依存するビューやテーブルをダンプする可能性があった（Bug#44939、Bug#11753490）。