主な変更点
■ アカウント管理関連
・以前は、DROP ROLE権限を持っていたユーザーがDROP ROLEステートメントを使ってロックまたは ロック解除されたアカウントを削除することができました。現在、DROP ROLE権限を持つユーザーは DROP ROLEを使用して、ロックされているアカウントのみを削除できます（ロック解除された アカウントは、単にロールとしてではなく、おそらくサーバーへのログインに使用されるユーザー アカウントである）。CREATE USER権限を持つユーザーは、DROP ROLEを使用してロックまたは ロック解除されているアカウントを削除できます。（Bug #28953158、Bug #93263） ・MySQLのアカウント管理機能にいくつかの変更が加えられました。 * MySQLは、現在、ユーザーアカウントカテゴリーの概念を取り入れており、システムユーザーと 通常ユーザーは新しいSYSTEM_USER特権を持っているかどうかによって区別されます。 ・システムユーザーとは、SYSTEM_USER権限を持つユーザーです。システムユーザーは、 システムアカウントと通常のアカウントの両方で操作を実行できます。 ・通常ユーザーとは、SYSTEM_USER権限を持たない一般的なユーザーです。通常ユーザーは 通常のアカウントに対して操作を実行できますが、システムアカウントに対しては 実行できません。 ユーザーが通常のアカウントに対して特定の操作を実行するための適切な権限を持っている場合、 SYSTEM_USERを使用すると、ユーザーはシステムアカウントに対してその操作を実行することも 可能です。SYSTEM_USERは他の権限を意味しないので、特定のアカウント操作を実行するための 機能は、他の必要な権限の所有を前提としていることに変わりありません。例えば、ユーザーが 通常のアカウントにSELECTおよびUPDATE権限を付与できる場合、SYSTEM_USERを使用して システムアカウントにSELECTおよびUPDATE権限を付与することもできます。 システムアカウントと通常アカウントを区別することは、SYSTEM_USER権限を持つアカウントを その権限を持たないアカウントから保護することによって、特定のアカウント管理の問題を より適切に制御できるようにします。例えば、CREATE USER権限は、新しいアカウントの作成だけで なく、既存のアカウントの変更と削除も可能にします。システムユーザーの概念がなくても、 CREATE USER権限を持つユーザーは、rootアカウントを含む既存のアカウントを変更または削除 できます。システムユーザーの概念により、rootアカウント（それ自体がシステムアカウント） への変更を制限することが可能なため、その変更はシステムユーザーのみが行うことが可能です。 CREATE USER権限を持つ通常のユーザーは既存のアカウントを変更または削除できますが、通常の アカウントのみです。 SYSTEM_USER権限のその他の操作上の意味： ・SYSTEM_USER権限を持つセッションは、他の必要な権限に加えて、SYSTEM_USER権限を持つ ユーザーのみが強制終了できます。 ・SYSTEM_USER権限を持つアカウントは、他の必要な権限に加えて、SYSTEM_USER権限を持つ ユーザーのみがストアドオブジェクトのDEFINERとして指定できます。 ・SYSTEM_USER権限を持つロールをmandatory_rolesシステム変数の値に記載することは できません。 * 以前は、特定のスキーマを除いて、グローバルに適用される権限を付与することはできませんでした。 これは、現在、新しいpartial_revokesシステム変数が有効になっている場合に可能になります。 例えば、次のステートメントは、アカウントがmysqlシステムスキーマのテーブル以外のテーブルから 選択または挿入することを可能にします。 SET PERSIST partial_revokes = ON; GRANT SELECT, INSERT ON *.* TO u1; REVOKE SELECT, INSERT ON mysql.* FROM u1; サーバーは、mysql.userシステムテーブルのUser_attributes列にRestrictions属性を 追加することによって、一部の無効を記録します。SHOW GRANTSは、一部の無効を示すために、 その出力にREVOKEステートメントを含みます。 * GRANTステートメントには、ステートメントの実行に使用する権限コンテキストに関する追加情報を 指定する新しいASユーザー[WITH ROLE]句があります。この構文はSQLレベルで見ることができますが、 その主な目的は、一部の無効によって与えられる付与者権限の制限をバイナリログに表示することに よって、その制限についてすべてのノードで統一されたレプリケーションを可能にすることです。
■ C API関連
・MySQL C APIは、現在、MySQLサーバーとのノンブロッキング通信のための非同期関数をサポートして います。 * mysql_real_connect_nonblocking() * mysql_real_query_nonblocking() * mysql_store_result_nonblocking() * mysql_next_result_nonblocking() * mysql_fetch_row_nonblocking() * mysql_free_result_nonblocking() 各関数は、接尾語 _nonblocking無しの場合に同じ名前の同期関数の非同期の対応するものです。 サーバー接続からの読み取りまたはサーバー接続への書き込みが待機しなければならない場合、 同期機能はブロックします。非同期関数は、アプリケーションがサーバー接続上の作業を進める準備が できているかどうかを確認できるようにします。準備できていない場合、アプリケーションは後で 再度確認する前に他の作業を実行できます。
■ キャラクターセット関連
・MySQLは、utf8mb4 Unicodeキャラクターセットに関して、新しい中国語の照合 utf8mb4_zh_0900_as_cs をサポートするようになりました。utf8mb4_zh_0900_as_csは、MySQLのUnicodeで利用可能な最初の 中国語固有の照合です。この照合は、アクセントを区別し、大文字と小文字を区別します。その特性は、 utf8mb4_0900_as_csと似ていますが、言語固有の規則が適用可能な場合に優先される点が異なります。
■ コンパイル関連
・CMakeは、Clang用のllvm lldリンカーが利用可能であり、明示的に無効にされていない場合、 ビルドプロセスをllvm lldリンカーとリンクさせるようになりました。このリンカーの使用を 無効にするためには、-DUSE_LD_LLD=OFFオプションを指定してください。（Bug＃29264211） ・EL6、EL7上のビルドは、devtoolset-7ではなくdevtoolset-8でコンパイラを使用しようとするように なりました。（Bug＃29198846） ・サーバー構築用Boostライブラリの最小バージョンが1.69.0になりました。（Bug＃29114233） ・Visual Studio 2017のための設定時チェックが十分に詳細ではありませんでした。MySQLコンパイルの チェックには、少なくともVisual Studio update 15.8、つまりバージョン番号1915が必要です。 （Bug＃28970895） ・MySQLは、C++14を使用してコンパイルできるようになりました。以下の最小バージョン要件は、 コンパイラサポートに適用されます。 * GCC 5.3 (Linux) * Clang 4.0 (FreeBSD) * XCode 9 (MacOS) * Developer Studio 12.6 (Solaris) * Visual Studio 2017 (Windows)
■ 設定関連
・MySQLの設定に必要な最小CMakeバージョンは3.4.3です。一部のRed HatおよびOracle Linux プラットフォームでは、cmakeではなくcmake3を使用する必要があります。（Bug＃29246216） ・WITH_LZMA CMakeオプションが削除されました。（Bug＃29153932、Bug＃93755） ・EXCLUDE_FROM_ALLオプションがCMake設定で適切に使用されるようになりました。そのため、 ライブラリは、実際に実行ファイルによって使用される場合にのみビルドされます。（Bug＃29052599） ・新しいWITH_JEMALLOC CMakeオプションは、-ljemallocとリンクするかどうかを示します。 有効にすると、組み込みのmalloc()、calloc()、realloc()、およびfree()ルーチンは無効に なります。デフォルトはOFFです。（Bug＃29027974） ・新しいWITH_LSAN CMakeオプションは、AddressSanitizerなしでLeakSanitizerを実行するか どうかを示します。デフォルトはOFFです。（Bug＃28936574） ・新しいWITH_ROUTER CMakeオプションは、MySQLルーターをビルドするかどうかを示します。 デフォルトはONです。（Bug＃28759234） ・MySQLサーバーは、--validate-configオプションをサポートするようになりました。これにより、 サーバーを通常の操作モードで起動しなくても、スタートアップ設定に問題がないか確認することが できます。
■ 廃止予定と削除
・TempTableストレージエンジンは、常にInnoDBを使用してディスク上の内部一時テーブルを 管理するようになりました。また、このタスクに使用されるストレージエンジンの選択は、 ユーザー設定できなくなりました。internal_tmp_disk_storage_engineシステム変数は 削除されました。（Bug＃91377、Bug＃28234637） 参照：Bug #28081038、Bug #82556、Bug #27408352。
■ インストール関連
・以前は、新しいバージョンのMySQLのインストール後、MySQLサーバーは次回の起動時に データディクショナリテーブルを自動的にアップグレードしました。その後、DBAは mysql_upgradeを手動で呼び出してmysqlスキーマ内のシステムテーブルとsysスキーマや ユーザースキーマなどの他のスキーマ内のオブジェクトをアップグレードすることを期待されました。 現在、サーバーは、前にmysql_upgradeによって処理されたタスクを実行します。新しいMySQLバージョン のインストール後、サーバーは次回の起動時に必要なすべてのアップグレードタスクを自動的に実行し、 mysql_upgradeを呼び出すDBAには依存しなくするようになりました。さらに、サーバーはhelpテーブルの 内容を更新します（mysql_upgradeが実行しなかったこと）。新しい--upgradeサーバーオプションは、 サーバーがデータディクショナリとサーバーの自動アップグレード操作を実行する方法を制御します。 アップグレード手順へのこの変更によって、いくつかの廃止予定のものが出ました： * mysql_upgradeは不要になったため廃止予定です。 * --no-dd-upgradeサーバーオプションは、--upgradeオプションがそれにとって代わるため、 廃止予定です。 mysql_upgradeと--no-dd-upgradeオプションは、将来のMySQLバージョンで削除される予定です。 （Bug #28146052、Bug #28162609、Bug #91205、Bug #29185739、Bug #27740692、 Bug #28547424、Bug #91961）
■ パッケージング関連
・システムのcurlライブラリにリンクするのではなく、curlを含んでいるバイナリパッケージは、現在、 curl 7.64.0を使用します。（Bug＃29357198） ・Henry Spencer正規表現ライブラリ（extra/regex）は、MySQL 8.0では使用されなくなり、 ソースの配布物にはもう含まれていません。（Bug＃29192306） ・RPMパッケージは、新しいバージョンのglibcにSun RPCが含まれていないため、libtirpcとrpcgenに 依存するようになりました。（Bug＃28995257） ・support-files/magicファイルは、MySQLソースツリーから削除されました。ほとんどの MySQLファイルフォーマットは、オペレーティングシステムのファイルタイプ機能によって カバーされています。（Bug＃18335080、Bug＃71898）
■ パーサー関連
・パーサーは、テーブルの別名を指定するための文書化されておらず標準ではないalias_name構文を
受け付けなくなりました。（Bug＃29205289）
・パーサーは、現在、いくつかの追加の予約語ではないキーワードを以前はそのような使用から
制限されていたストアドプログラム内のラベルとして使用することを許可しています：
ACCOUNT、ALWAYS、BACKUP、CLOSE、FORMAT、GROUP_REPLICATION、HOST、INVISIBLE、
OPEN、OPTIONS、OWNER、PARSER、PORT、REMOVE、RESTORE、ROLE、SECONDARY、
SECONDARY_ENGINE、SECONDARY_LOAD、SECONDARY_UNLOAD、SECURITY、SERVER、SOCKET、
SONAME、UPGRADE、VISIBLE、WRAPPER。（Bug＃29033659）
・パーサーは、外部結合のODBCエスケープ構文（{OJ outer_join}）を受け入れましたが、OJ以外の
識別子も受け入れました。現在、パーサーはOJのみを受け入れます。
注意：OJは、現在予約語ではないキーワードです。
（Bug＃22320942）
■ パフォーマンススキーマ関連
・MySQLには、現在、パフォーマンススキーマデータをフォーマットまたは取得する組み込みSQL関数や、 既存のsysスキーマストアド関数と同等のものとして使用され得る組み込みSQL関数が含まれています。 * FORMAT_BYTES()：バイト数を単位付きの値に変換します。sys.format_bytes()と同様です。 * FORMAT_PICO_TIME()：ピコ秒の時間を単位付きの値に変換します。sys.format_time()と同様です。 * PS_THREAD_ID()：特定のスレッド用のパフォーマンススキーマスレッドIDを返します。NULL以外の 引数で呼び出されるsys.ps_thread_id()と同様です。 * PS_CURRENT_THREAD_ID()：現在のスレッドのパフォーマンススキーマスレッドIDを返します。 NULL引数で呼び出されるsys.ps_thread_id()の簡単な方法。 sys関数はsys.スキーマ修飾子を必要とするか、sysが現在のスキーマであることを必要とするのとは 異なり、組み込み関数は任意のスキーマで呼び出すことができ、修飾子を必要としません。 組み込み関数は、対応するsys関数に取って代わります。sys関数は現在廃止予定で、将来の MySQLバージョンで削除される予定です。sys関数と組み込み関数の間にいくつかの小さな違いが あることを念頭に置いて、sys関数を使用するアプリケーションは、代わりに組み込み関数を 使用するように調整される必要があります。 ・パフォーマンススキーマの新しいkeyring_keysテーブルは、MySQLキーリングのキーのメタデータを 見えるようにします。キーメタデータには、キーID、キー所有者、バックエンドキーIDが含まれます。 keyring_keysテーブルは、キーの内容などの機密のキーリングデータを一切公開しません。
■ プラグイン関連
・MySQLには、現在、サーバーが受信したCREATE TABLEステートメントをサーバーが解析して実行する 前に変更するddl_rewriterプラグインが含まれます。このプラグインは、暗号化されたデータベース またはデータディレクトリ外に格納されたテーブルを持つデータベースから作成されたSQLダンプファイル からテーブルを復元する場合に役立つENCRYPTION、DATA DIRECTORY、INDEX DIRECTORY句を 削除します。例えば、このプラグインを使用すると、そのようなダンプファイルを暗号化されていない インスタンスに復元することや、データディレクトリの外側のパスがアクセスできない環境に復元する ことができます。インストールされると、ddl_rewriterは、プラグインのメモリの使用状況を追跡する ためにパフォーマンススキーマのmemory/rewriter/ddl_rewriterインストゥルメントを見えるように します。
■ セキュリティ関連
・以前は、grantテーブルが破損していた場合、MySQLサーバーはエラーログにメッセージを書き込み ましたが、--skip-grant-tablesオプションが指定されているかのように継続していました。 これにより、--skip-grant-tablesが実際に指定されていない限り、サーバーは予想しない状態で 動作していたことになります。現在、--skip-grant-tablesで起動しない限り、サーバーは エラーログにメッセージを書き込んだ後停止します。（そのオプションを指定してサーバーを 起動すると、接続して診断操作を実行できます。）（Bug＃29394501、Bug＃94394） ・いくつかのプラットフォーム（Windows、macOS、汎用Linux）上のMySQLにバンドルされている OpenSSLライブラリがバージョン1.0.2rに更新されました。他のすべてのプラットフォームでは、 MySQLはOpenSSLをインストールされたシステムを使用します。OpenSSLの新しいバージョンで 修正された問題は、http://www.openssl.org/news/vulnerabilities.htmlで説明されています。 （Bug #28988091） ・匿名ユーザーにロールを付与することは、問題のある動作の原因となったため、サポートされなく なりました。（Bug＃28910120） ・OpenSSL 1.1.1は暗号化接続用のTLS v1.3プロトコルをサポートしており、MySQLは OpenSSL 1.1.1以降を使用してコンパイルされた場合、同様にTLS v1.3をサポートするように なりました。 * 一部のTLSv1.3暗号スイートは、デフォルトで有効になっています。 tls_ciphersuitesシステム変数を有効にすると、サーバーが許可するTLSv1.3暗号スイートを 明示的に指定できます。 * --tls-ciphersuitesクライアントオプションを有効にすると、クライアントが許可する TLSv1.3暗号スイートを指定できます。このオプションは、次のプログラムに適用されます： mysql、mysqladmin、mysqlbinlog、mysqlcheck、mysqldump、mysqlimport、 mysqlshow、mysqlslap、mysqltest、mysql_secure_installation、およびmysql_upgrade。 * mysql_options() C API関数に新しいMYSQL_OPT_TLS_CIPHERSUITESオプションが追加され、 クライアントライブラリ内からクライアントプログラムが許可するTLSv1.3暗号スイートを 指定できるようになりました。 注意：現在、グループレプリケーションはTLSv1.3をサポートしていません。 ・サーバーが新規接続に使用するSSLコンテキストは、現在、実行時に再設定可能です。この機能は、 例えば、長い時間実行しているためにSSL証明書が期限切れになったMySQLサーバーを再起動するのを 避ける場合に、便利です。 動的SSL再構成可能性は、以下の変更に基づいています。 * SSLコンテキストを定義するシステム変数は動的であり、実行時に変更できます： ssl_ca、ssl_capath、ssl_cert、ssl_cipher、ssl_crl、ssl_crlpath、ssl_key、 tls_ciphersuites、tls_version。 * ALTER INSTANCEステートメントは、コンテキストを定義するシステム変数の現在の値から SSLコンテキストを再設定するRELOAD TLSアクションをサポートしています。 * これらのステータス変数は、サーバーが新しい接続に使用するSSLコンテキストを反映しています： Current_tls_ca、Current_tls_capath、Current_tls_cipher、Current_tls_ciphersuites、 Current_tls_crl、Current_tls_crlpath、Current_tls_crlpath、Current_tls_key、 Current_tls_version。 ALTER INSTANCE RELOAD TLSは、SSLコンテキストを再設定する時に、対応するシステム変数の値から これらのステータス変数を更新します。 参照：Bug #27980097。 ・MySQL 8.0では、デフォルトの認証プラグインがmysql_native_passwordからcaching_sha2_passwordに 変更されました。caching_sha2_passwordはsha256_password認証プラグインの機能のスーパーセットを 提供するため、sha256_passwordは現在廃止予定で、将来のMySQLバージョンで削除される予定です。 sha256_passwordを使用して認証を行うMySQLアカウントは、代わりにcaching_sha2_passwordを 使用するように移行する必要があります。
■ 空間データサポート
・ST_Length()関数は、現在、戻り値の単位を指定することができるオプションの第2引数を取ります。 許可されている単位は、新しいINFORMATION_SCHEMA ST_UNITS_OF_MEASUREテーブルにリストされている 単位です。
■ SQL構文関連
・互換性のない変更：MySQL 5.7では、CONSTRAINTシンボル句を指定せずにInnoDBテーブルに FOREIGN KEY定義を指定するか、シンボルを指定せずにCONSTRAINTキーワードを指定すると、InnoDBは 生成された制約名を使用します。その動作はMySQL 8.0で変更され、InnoDBは生成された名前の代わりに FOREIGN KEY index_nameの値を使用しました。制約名はスキーマ（データベース）ごとに一意で なければならないため、この変更はスキーマごとに一意ではない外部キーインデックス名による エラーを引き起こしました。このようなエラーを回避するために、この新しい制約命名動作は元に戻され、 InnoDBは生成された制約名を再び使用するようになっています。 InnoDBとの一貫性を保つために、CONSTRAINTシンボル句が指定されていない場合、またはCONSTRAINT キーワードがシンボルなしで指定されている場合、NDBストレージエンジンは現在、生成された制約名を 使用するようになりました。MySQL 5.7およびこれまでのMySQL 8.0リリースに基づくNDBリリースでは、 NDBはFOREIGN KEY index_nameの値を使用しました。 上記の変更により、以前の外部キー制約の命名動作に依存するアプリケーションについて非互換性が 発生する可能性があります。（Bug＃29173134） ・以前は、MySQLは限られた形式のCHECK制約構文を許可していましたが、それを解析して無視しました。 MySQLは、現在、すべてのストレージエンジンに対して、テーブルと列のCHECK制約のコア機能を実装 しています。制約は、CREATE TABLEステートメントとALTER TABLEステートメントを使用して定義され ます。（Bug＃11744849、Bug＃3464、Bug＃3465、Bug＃11746042、Bug＃22759）
■ テストスイート関連
・mysql-test-run.plは、現在、MTR_UNIQUE_IDS_DIR環境変数に対応しています。この環境変数を 設定して、複数の同時mysql-test-run.plインスタンスによってすべてのchroot環境の共通の場所として 使用されるunique-IDディレクトリを指定することができます。これにより、これらのインスタンスは ポート番号を予約する時の競合を回避できます。（Bug＃29221085、Bug＃93950） ・my_safe_processプログラムは、mysqltest_safe_processに名前が変更され、テストスイートファイル ではなくmysqltestのような他のバイナリと共にインストールされるようになりました。 （Bug＃29198969） ・all_persisted_variablesテストに関して以下の変更が実装されました。 * テスト出力内のハードコードされた値をローカル変数に入れることによって、その数を制限します。 新しいシステム変数を追加するために上にリベースされる新しいパッチは、元のテストケースの多くの 行を変更する必要がないため、リベースプロセスが簡単になります。 * 修正されたバグのエントリを削除し、未解決のバグのためにテストされなかったシステム変数を 含むようにクエリを修正します。 （Bug＃29013375、Bug＃93478）
■ Xプラグイン関連
・クエリのクリーンアップが終了し、セッションが無効化された後、以前XプラグインはStmtExecuteOk メッセージをクライアントに返していました。そのメッセ―ジは、結果が明らかになるとすぐに、 クエリのクリーンアップの前に、返されるようになりました。これによってパフォーマンスが大幅に 向上しました。 （Bug＃28997370） ・I/Oインタフェースの準備に失敗したためにユーザー接続ができなかった場合、Xプラグインは システムメッセージ "X Plugin ready for connections"をログに記録しました。（Bug＃28906360） ・Xプラグインのコードの一部の項目は、デフォルトでパフォーマンススキーマに対応していませんでした。 （Bug＃28898155） ・Xプロトコルは、現在、COM_RESET_CONNECTIONユーティリティコマンドをサポートし、再認証や接続の 切断をせずにセッション状態をリセットすることができます。（Bug＃28732455） ・Clang 8コンパイラを使用してMySQLサーバーのソースコードがビルドされると、Xプラグインは コンパイル警告を生成しました。 （Bug＃28732158）
■ 追加・変更された機能
・InnoDB：TempTableストレージエンジンのメモリ使用量がtemptable_max_ram変数で定義された制限を 超えると、TempTableストレージエンジンは内部インメモリー一時テーブル用の領域を メモリマップドテンポラリファイルとして割り当てます。この動作は、現在、temptable_use_mmap変数 によって制御されます。この変数を無効にして、TempTableストレージエンジンに InnoDBオンディスク内部一時テーブルを代わりに使用させることができます。（Bug＃28944457） ・InnoDB：undoログの切り捨てに関連するバックグラウンドアクティビティを監視するために、 undoおよびpurgeサブシステムカウンターが追加されました。カウンターの名前と説明については、 INFORMATION_SCHEMA.INNODB_METRICSテーブルに問い合わせを行ってください。 SELECT NAME, SUBSYSTEM, COMMENT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE '%truncate%'; （Bug #28813526） ・InnoDB：新しいinnodb_spin_wait_pause_multiplier変数により、スレッドがmutexまたはrw-lockを 取得するのを待つ時に発生するスピンロックのポーリングの遅延時間をより細かく制御できます。 それぞれのプロセッサーアーキテクチャのPAUSE命令の長さの違いを考慮して、遅延をより細かく 調整できるようになりました。 ・InnoDB：修正されたページの追跡をサポートするために、内部サービスインターフェースが 追加されました。 ・InnoDB：InnoDBの保存データ（data-at-rest）暗号化機能は、現在、mysqlシステムテーブルスペースの 暗号化をサポートします。mysqlシステムテーブルスペースには、mysqlシステムデータベースと MySQLデータディクショナリテーブルが含まれます。 ・以前実行時に評価されていたInnoDBのメモリ割り当て関数の中には、現在コンパイル時に 評価されるものがあり、結果的にパフォーマンスが向上します。（Bug＃29370811、Bug＃94380） ・INサブクエリの準結合の最適化は、EXISTSサブクエリでも同様に動作するように拡張されました。 現在、これらをINサブクエリと同じ準結合方式で処理できます。これらには、 最初の一致（first-match）、実体化（materialization）、重複削除、ルースインデックススキャンが 含まれます。 さらに、オプティマイザーはサブクエリに付加されたWHERE条件内の自明な相関等価述部を非相関化に するので、それらはINサブクエリ内の式と同様に扱われることが可能です。非相関化は、現在、 EXISTSサブクエリと同様にINサブクエリに対しても実行されます。 準結合操作に変換されるINサブクエリに適用可能なすべてのヒントおよびオプティマイザスイッチは、 変換されたEXISTSサブクエリにも適用可能です。このようなINサブクエリの最適化に対する制限は すべて、変換されたEXISTSサブクエリにも適用されます。（Bug＃28805105、Bug＃28857990） ・SQL準拠のRDBMSや他のRDBMSとの整合性を保つために、テーブルのエイリアスが複数テーブルの DELETEステートメントと同様に単一テーブルでもサポートされるようになりました。（Bug＃27455809） ・グループレプリケーションのグループ通信エンジン（XCom、Paxosの一種）は、コンセンサスプロトコル の一部としてグループメンバー間で交換されるメッセージ（およびそれらのメタデータ）のための キャッシュを含みます。他の機能の中で、メッセージキャッシュは、他のグループメンバーと 通信できなかった期間の後にグループに戻ったメンバーによって回復に使用されます。 以前は、メッセージキャッシュのサイズ制限は1GBのメモリに固定され、キャッシュ内の 最大メッセージ数も固定されていました。ただし、 group_replication_member_expel_timeoutシステム変数（MySQL 8.0.13で導入）は、 除かれるのではなく、メンバーがグループに戻るために1時間まで許可するように設定できるように なりました。キャッシュのサイズに1GBの固定された制限があるため、そのようなノードは 通信を再確立するのに失敗したというメッセージを回復することができないことがありました。 このような理由で、MySQL 8.0.16以降、XComのメッセージキャッシュに格納できるメッセージ数に 固定の制限はなく、使用できるメモリ量に対して設定された制限によってのみ制限されます。 キャッシュサイズの制限は、新しいgroup_replication_message_cache_sizeシステム変数を使用して 設定できます。MySQLサーバーの以前のバージョンで使用されていたようにデフォルトで最小の設定は 1GBです。キャッシュサイズの上限に達すると、XComは決定され配信された最も古いエントリを削除 します。キャッシュサイズの制限は、実行時に動的に増減できます。キャッシュサイズの制限を減らすと、 XComは現在のサイズがその制限を下回るまで決定され配信された最も古いエントリを削除します。 グループレプリケーションのグループ通信システム（GCS）は、現在到達不能なメンバーによる復元に 必要と思われるメッセージがメッセージキャッシュから削除されると、警告メッセージによって 警告します。（Bug＃26482507） ・グループレプリケーションのグループメンバー間で送信される大きなメッセージは、ユーザー定義の しきい値のサイズを超えた時に複数のメッセージに分割できるようになりました。異常に大きい メッセージを送信すると、一部のグループメンバーが失敗したと報告され、グループから除かれることが あります。これは、グループ通信エンジン（XCom、Paxosの一種）によって使用される単一スレッドが メッセージの処理に時間がかかりすぎるため、グループメンバーの一部が受信側に失敗したと報告する 可能性があるためです。 新しいシステム変数group_replication_communication_max_message_sizeを使用して、 グループレプリケーション通信の最大メッセージサイズを指定できます。このサイズを超える メッセージは、自動的にフラグメントに分割され、別々に送信されて受信者によって 再組み立てされます。断片化されたメッセージのメッセージ配信は、メッセージのすべての断片が すべてのグループメンバーによって受信され再組み立てされた時に完了したと見なされます。 断片化はデフォルトで適用され、システム変数にゼロ値を指定することによってオフにすることが できます。 MySQLサーバーの以前のリリースではメッセージの断片化はサポートされていないため、下位互換性を 確保するために、グループレプリケーションには、現在、グループ用通信プロトコルの概念が 追加されています。通信プロトコルのバージョンは、グループにサポートさせたい最も古い MySQLサーバーのバージョンに対応するように設定されます。バージョンXのMySQLサーバーは、 グループの通信プロトコルのバージョンがX以下の場合にのみ、レプリケーショングループに参加して レプリケーショングループのONLINEステータスに達することができます。 新しいUDFであるgroup_replication_get_communication_protocol()を使用すると、 グループによって使用されている通信プロトコルを調べることができます。これは、グループが サポートする最も古いMySQLサーバーのバージョンを返します。MySQL 5.7.14以降のバージョンでは メッセージを圧縮でき、MySQL 8.0.16以降のバージョンでもメッセージを断片化できます。 新しいメンバーはレプリケーショングループに参加すると、そのグループの既存のメンバーによって アナウンスされる通信プロトコルのバージョンを確認します。参加メンバーがそのバージョンを サポートしている場合、そのメンバーは追加の通信機能をサポートしていても、そのグループに参加し、 そのグループがアナウンスした通信プロトコルを使用します。参加メンバーがその通信プロトコルの バージョンをサポートしていない場合、グループから追放されます。 以前のリリースのメンバーが参加できるようにするために、グループの通信プロトコルバージョンを 変更する必要がある場合は、新しいUDFのgroup_replication_set_communication_protocol()を 使用して、許可したい最も古いメンバーのMySQLサーバーのバージョンを指定します。これにより、 可能であれば、グループは互換性のある通信プロトコルバージョンに戻します。 レプリケーショングループのすべてのメンバーを新しいMySQLサーバーリリースにアップグレードする 場合、グループの通信プロトコルのバージョンは自動的に一致するようにアップグレードされません。 以前のリリースのメンバーをサポートする必要がなくなった場合は、 group_replication_set_communication_protocol() UDFを使用して、通信プロトコルの バージョンを、メンバーをアップグレードした新しいMySQLサーバーのバージョンに設定します。 （Bug＃26438884、Bug＃23240361、Bug＃28474580、Bug＃91830、Bug＃28642504、Bug＃26941977、 Bug＃29240931） ・グループレプリケーションに関して、メンバーが追放された場合、または、 group_replication_unreachable_majority_timeout設定に達する前にグループの大部分と 連絡が取れない場合、新しいシステム変数group_replication_autorejoin_triesで メンバーが自動的にグループに再参加を試みる回数を指定できます。デフォルト設定の0は、 メンバーが再参加を試みずに、group_replication_exit_state_actionシステム変数によって 指定されたアクションに進むことを意味します。 古い読み取りの可能性を許容でき手動介入の必要性を最小限に抑えたい場合、特に一時的なネットワークの 問題がかなり頻繁にメンバーの追放をもたらす場合は、自動再参加を有効にしてください。 試行回数を指定した場合、メンバーの追放または到達不能な多数のタイムアウトに達すると、 （現在のプラグインオプションの値を使用して）再参加を試み、その後、指定した試行回数まで さらに自動再参加を試み続けます。自動再参加の試行に失敗した後、メンバーは次の試行まで 5分待機します。自動再参加の進行中、メンバーはスーパーリードオンリーモードのままで、 レプリケーショングループのビューにエラー状態を表示します。メンバーは、 STOP GROUP_REPLICATIONステートメントを使用するかサーバーをシャットダウンすることに よっていつでも手動で停止できます。指定された試行回数がメンバーの再参加または停止なしに 使い果たされた場合、メンバーはgroup_replication_exit_state_actionシステム変数で指定された アクションに進みます。これは、スーパーリードオンリーモードのままにするかシャットダウンするかの いずれかを行えます。 （Bug＃25673350、Bug＃84784、Bug＃28732174） ・定数と列型との比較において、定数が列の型に対して範囲外または型が間違っているWHERE条件は、 現在、実行時ではなく最適化時に処理されます。例えば、型がTINYINT UNSIGNEDの列cを持つ テーブルtがある場合、クエリSELECT * FROM t WHERE c < 256の条件は、 256はこの型の列の範囲外であるためSELECT * FROM t WHERE TRUEに折りたたむことができます。 NULL列との比較も最適化できます。列cがNULL可能である場合、 SELECT * FROM t WHERE c IS NOT NULLとして同じクエリを最適化できます。 この方法で処理できる比較は、>、> =、<、<=、=、<> /！=、<=>です。 （BETWEENとINは現在サポートされていません。） 範囲と型に基づいて比較を折りたたむことができる型には、整数、浮動小数点、固定小数点の数値型が あります。BITはこの最適化ではサポートされていませんし、日付と時刻型の列もサポートされて いません。 （Bug＃90100、Bug＃25484743、Bug＃29048682、Bug＃27703371） 参照：Bug #28172538。 ・MySQLサーバーでバイナリログおよびリレーログの暗号化を使用している場合 （binlog_encryption=ON）、ALTER INSTANCE ROTATE BINLOG MASTER KEYを発行することによって サーバーが稼働している間はいつでもバイナリログマスタキーを交させることができます。 組織のセキュリティポリシーを遵守するために定期的にこれを行うことができます。また、 現在または以前のバイナリログマスターキーが危険にさらされている可能性があると思われる場合も 同様です。 バイナリログマスターキーをローテーションさせると、新しいマスターキーはキーが再度変更されるまで 新しいバイナリログファイルとリレーログファイル、およびそれ以降のファイルのファイルパスワードを 暗号化するために使用されます。サーバー上の既存の暗号化されたバイナリログファイルおよび リレーログファイルのファイルパスワードも、最新のファイルから、新しいバイナリログマスターキーを 使用して順番に再暗号化されます。暗号化されていないファイルはすべてスキップされます。最後に、 保持されているバイナリログファイルやリレーログファイルに適用されなくなったすべての バイナリログ暗号化キーは、キーリングから削除されます。 ・暗号化のデフォルトを定義して強制することで、テーブルの暗号化をグローバルに管理できるように なりました。default_table_encryption変数は、新しく作成されたスキーマおよび 一般テーブルスペースの暗号化デフォルトを定義します。スキーマの暗号化デフォルトは、 スキーマを作成する時にDEFAULT ENCRYPTION句を使用して定義することもできます。デフォルトでは、 テーブルはそれが作成されたスキーマまたは一般テーブルスペースの暗号化を継承します。 暗号化デフォルトは、table_encryption_privilege_check変数を有効にすることによって強制 されます。権限チェックは、default_table_encryption設定とは異なる暗号化設定でスキーマ または一般テーブルスペースを作成または変更する時、または、デフォルトのスキーマ暗号化とは 異なる暗号化設定でテーブルを作成または変更する時に、発生します。 table_encryption_privilege_checkが有効な場合、TABLE_ENCRYPTION_ADMIN権限はデフォルトの 暗号化設定を上書きすることを許可します。 ・システム変数group_replication_exit_state_actionは、サーバーインスタンスが意図せずに グループを離れた時のグループレプリケーションの動作を指定します。例えばアプライヤーエラーに 遭遇した後、または、大多数の損失の場合、または、グループの別のメンバーがタイムアウトの 疑いのためにそれを追放した場合などです。システム変数が導入される前は、このような状況での サーバーの応答は、システム変数super_read_onlyをONに設定することでMySQLを スーパーリードオンリーモードに切り替えることでした。group_replication_exit_state_actionは、 サーバーが自動的にシャットダウンするための代替オプションを提供しました。これにより、 古い読み取りの可能性が最小限に抑えられ、サーバーの障害を事前に監視する必要がなくなります。 このシステム変数がMySQL 5.7.24およびMySQL 8.0.12で導入された時、デフォルトは既存の動作との 互換性のために5.7ではREAD_ONLYに設定され、8.0ではABORT_SERVERに設定されました。 ユーザーからのフィードバックを受けて、デフォルトはMySQL 8.0.16からREAD_ONLYに変更されました。 ・パーティションテーブルへの挿入、削除、または更新が行われた時、現在、バイナリログには パーティションと（もしあれば）行イベントが発生したサブパーティションに関する情報が記録されます。 関連するテーブルが同じであっても、別のパーティションまたはサブパーティションで行われた変更に 対して新しい行イベントが作成されます。そのため、トランザクションに3つのパーティションまたは サブパーティションが含まれる場合、3つの行イベントが生成されます。更新イベントの場合、 パーティション情報は"前"のイメージと"後"のイメージの両方に関して記録されます。 mysqlbinlogを使用してバイナリログを表示する時に-vまたは--verboseオプションを指定する場合、 パーティション情報が表示されます。パーティション情報は、行ベースのロギングが使用されている場合 （binlog_format=ROW）にのみ記録されます。
■ 主なバグ修正
・NDB Cluster：テーブルアクセスタイプeq_refで実行されたクエリのEXPLAINは、条件プッシュダウンが そのクエリに対してサポートされていなかった時でも、条件がプッシュダウンされていると示す可能性が ありました。現在、NDBが可能性のあるプッシュダウン最適化について条件をチェックする前に、 アクセスタイプがチェックされるようになりました。 この修正は、プッシュ型結合の一部であるテーブルの処理には影響しません。これに関して、 NDBは以前と同様にプッシュ型条件をサポートし続けます。（Bug＃27429615） 参考：Bug＃27397802、Bug＃27808758、Bug＃90301。 ・InnoDB：起動時にUNDOテーブルスペースの暗号化を有効にした後、UNDOテーブルスペースが 暗号化されないままになった。 （Bug＃29477795） ・InnoDB：MySQL 8.0.14のUNDOテーブルスペースのDDLサポートで導入された問題のあるマクロは、 修正されました。（Bug＃29324132、Bug＃94243） ・InnoDB：誤ったスコープで定義された静的スレッドローカル変数がスレッド終了時に解放されません でした。（Bug＃29305186） ・InnoDB：performance_schema.data_locksのLOCK_DATA列は、一意のセカンダリインデックスに 配置されたロックに関するロックされたレコードのセカンダリインデックスの値のみを示したため、 識別されたレコードの一意性を保証するのに十分ではありませんでした。ロックされたレコードの クラスタ化インデックス列の値が現在追加されています。（Bug＃29296645） ・InnoDB：XAトランザクションのリカバリにロールバックセグメントを使用しているトランザクションの 数が誤っているため、UNDOテーブルスペースの切り捨て操作は続行できず、パージスレッドは UNDOテーブルスペースが空になるのをチェックするために使用中のまま残りました。（Bug＃29273194） 参考：この問題はBug #29273194のレグレッションです。 ・InnoDB：圧縮されたテーブルごとのファイルのテーブルスペースのスペースIDの取得に失敗した後、 起動時に無効なアサーションが発生しました。無効なアサーションコードが削除されました。 （Bug＃29221385、Bug＃93760） ・InnoDB：最適化されたInnoDB内部のテンポラリテーブルはインプレースのUPDATE操作をサポートして いなかったために、削除マーク付きのレコード数が継続的に増加しました。大量の削除マーク付きの レコードは、予想よりも長いクエリ実行時間の原因となる可能性がありました。（Bug #29207450） ・InnoDB：Variance-Aware Transaction Scheduling（VATS）アルゴリズムのstd::sort関数は std::stable_sort関数に置き換えられ、等しい重みのトランザクションに対して元のFIFOの 順序を維持するようになりました。 （Bug＃29058967） ・InnoDB：誤って初期化された変数が原因で、先読みが期待通りに動作しませんでした。 (Bug #29028838, Bug #93442) ・InnoDB：生成された列の基本列情報が格納されていませんでした。（Bug #29021730） ・InnoDB：セカンダリインデックスの暗黙的なロックチェックは、照合規則を使用して列を不必要に 比較しました。（Bug＃29010725） ・InnoDB：innodb_flush_method O_DIRECT_NO_FSYNC設定に関連するアサーションコードが、最近の その設定への変更により、無効になりました。アサーションコードが改訂されました。（Bug #29007731） 参照：Bug #27309336。 ・InnoDB：UNDOログ暗号化を有効にしてサーバーを起動すると、新しく作成されたUNDOテーブルスペースの マスターキーはサーバーUUIDなしで生成されました。サーバーUUIDがまだ生成されていない場合は、 UNDOテーブルスペースはDefaultMasterKeyを使用する必要があります。（Bug＃29006275） ・InnoDB：データディクショナリコードは返されたデータディクショナリオブジェクトをチェックしません でした。これはnullポインタアクセスのためにサーバーを終了させる可能性がありました。 （Bug＃28977444、Bug＃93362） ・InnoDB：失敗したCREATE UNDO TABLESPACE操作により、UNDOテーブルスペースファイルが 残されました。（Bug＃28966457） ・InnoDB：ファイル名に無効な文字が含まれているため、Windows上でCREATE UNDO TABLESPACE ステートメントが失敗しました。UNDOテーブルスペースファイルを作成する呼び出しに OS_FILE_ON_ERROR_NO_EXIT属性が欠落しているために、その失敗によりハング状態が発生しました。 （Bug＃28955676） ・InnoDB：innodb_undo_log_encrypt変数の値を変更することは、操作が正常に完了したように見えた後に バックグラウンドスレッドによって変更が元に戻される可能性があるブロッキング操作ではありません でした。（Bug＃28952870） ・InnoDB：無効なデバッグアサーションは、temptable::Handler::primary_key_is_clustered関数から 削除されました。（Bug＃28949332） ・InnoDB：ALTER TABLE ... EXCHANGE PARTITION操作はデータディクショナリの列table_idの値を 正しく更新しませんでした。（Bug＃28927005） ・InnoDB：innochecksumユーティリティで発見されたメモリリークが削除されました。 （Bug #28917614、Bug #93164） ・InnoDB：仮想列にインデックスを作成しようとして失敗した後のDDL操作で、アサーションエラーが 発生しました。（Bug #28825718） ・InnoDB：サイズが128KB以下の圧縮されたBLOBに対する部分更新操作でパフォーマンスの低下が 見られました。（Bug＃28784301） ・InnoDB：集約クエリを実行するとValgrind警告が発生しました。 （Bug＃28711717） ・InnoDB：CHECK TABLE操作でアサーションエラーが発生しました。関数が終了する前に、ローカルの コールスタック変数へのポインタがnull設定に戻されていませんでした。（Bug＃28525110） ・InnoDB：DDLログ関数がER_TOO_MANY_CONCURRENT_TRXSエラーを処理するように修正されました。 （Bug＃28523127、Bug＃92071） ・InnoDB：パージスレッドがLOBデータページの解放に失敗しました。（Bug＃28510599） ・InnoDB：一部のDDLログテーブルトランザクションは、DDLログのリカバリーの前にロールバック されませんでした。（Bug＃28494969） ・InnoDB：テーブル名を取得するSHOW CREATE TRIGGERの処理中に呼び出された関数が、 期待される小文字変換を実行しませんでした。（Bug＃28351038） ・InnoDB：INFORMATION_SCHEMA.INNODB_FOREIGN TYPE列は不正な値を報告しました。 （Bug＃28315651、Bug＃91577） ・InnoDB：Linux AIOハンドラ関数は、完了したI/Oイベントが成功したかどうかの確認に失敗しました。 （Bug #27850600、Bug #90402） ・InnoDB：トランザクションがセカンダリインデックスの暗黙的ロックを保持しているかどうかを 確認するチェックでアサーションの失敗が発生しました。仮想列を含むセカンダリインデックスの列を 変更しないトランザクションは、暗黙的ロックを保持していると誤って判別される可能性がありました。 （Bug＃27491839） ・InnoDB：CREATE TABLEスレッドによって呼び出された関数が、バックグラウンドスレッドによって 解放された後にテーブルオブジェクトにアクセスしようとしました。(Bug #27373959, Bug #89126) ・InnoDB：INSERT ... ON DUPLICATE KEY UPDATE操作を同時に実行する2つのセッションで デッドロックが発生しました。タプルの部分的なロールバック中に、別のセッションがそれを更新する 可能性がありました。このバグに対する修正は、Bug #11758237、Bug #17604730、Bug #20040791に 対する修正を元に戻します。（Bug #25966845） ・InnoDB：結合テーブルへのアクセスに使用される方法がconstの場合、InnoDBが一致する行を 複数回アンロックしようとしました。（Bug #20939184） ・InnoDB：INFORMATION_SCHEMA.TABLESのINDEX_LENGTHの値は、インデックスの追加時に更新され ませんでした。（Bug #19811005） ・パーティショニング：誤ったテーブル識別子を使用した名前検証チェックが原因で、一部の パーティションDDLステートメントが不適切に拒否されました。（Bug＃29317007） ・パーティショニング：ALTER TABLE ... COALESCE PARTITIONをロールバックしている間に、 サーバーはこのステートメントの結果として削除されたパーティションをロックして クローズしようとすることがありました。(Bug #28517446) ・パーティショニング：ALGORITHM=INPLACEを使用したALTER TABLEステートメントによって パーティションテーブルに追加されたAUTO_INCREMENTキーが各パーティションで再起動しました。 （Bug #92241、Bug #28573894） ・レプリケーション：グループレプリケーションは、メンバーの グループレプリケーションローカルアドレスに指定されたポートが現在使用中である時に START GROUP REPLICATIONが発行された状況を正しく処理しませんでした。（Bug＃29347285） ・レプリケーション：WAIT_FOR_EXECUTED_GTID_SET()関数が小数部分を含むタイムアウト値（例：1.5） で使用された場合、キャストロジックのエラーは、タイムアウト値は最も近い整数秒に切り捨てられ、 1秒未満の値（例：0.1）の場合はゼロに切り捨てられることを意味します。キャストロジックは、 タイムアウト値が切り捨てなしで元の指定どおりに適用されるように修正されました。 （Bug #29324564、Bug #94247） ・レプリケーション：システム変数group_replication_consistencyの整合性レベルAFTERには、 BEFORE_ON_PRIMARY_FAILOVERによって提供される整合性保証が含まれていませんでした。 BEFOREおよびBEFORE_AND_AFTERの整合性レベルですでに暗黙的に存在していたこれらの整合性保証は、 現在、AFTERで提供されるようになりました。（Bug＃29315752） ・レプリケーション：Debianベースのプラットフォーム（Ubuntuなど）では、ホスト名が127.0.1.1 （これらのプラットフォームでのデフォルト）に解決された場合、デフォルト設定を使用して クラスタを作成することはできませんでした。現在、このような状況では、クラスタを作成して インスタンスをそれに追加する前に、インスタンスの適切な検証が実行されます。（Bug＃29246110） ・レプリケーション：ブロックされたグループで、group_replication_force_membersに無効な値を 設定してからSTOP GROUP_REPLICATIONを発行すると、サーバーが突然停止することがありました。 （Bug＃29119961） ・レプリケーション：mysql.gtid_executedテーブルにアクセスできない場合のMySQLサーバーの動作は、 適切なエラー応答とアクションを提供するためにリファクタリングされました。 MySQLサーバーは、 現在、サーバーが読み取り専用モードまたはスーパーリードオンリーモードの時に mysql.gtid_executedテーブルへの書き込みが確実に許可されています。そのため、 バイナリログファイルはこれらのモードでローテーションされることが可能です。 mysql.gtid_executedテーブルに書き込みのためにアクセスできず、バイナリログファイルが 最大ファイルサイズ（max_binlog_size）に達した以外の理由でローテーションされる場合、 現在のバイナリログファイルが引き続き使用されます。ローテーションを要求したクライアントに エラーメッセージが返され、警告がサーバーに記録されます。mysql.gtid_executedテーブルに 書き込みのためにアクセスできず、max_binlog_sizeに達した場合、サーバーは そのbinlog_error_action設定に従って応答します。IGNORE_ERRORが設定されている場合、 エラーがサーバーに記録され、バイナリロギングが停止されます。または、ABORT_SERVERが 設定されている場合、サーバーはシャットダウンします。（Bug＃29111514） ・レプリケーション：メンバーが大多数を失ったかどうかを評価しようとしている時に STOP GROUP_REPLICATIONを発行すると、サーバーが突然停止する可能性がありました。 （Bug＃29053128） ・レプリケーション：バイナリログファイルの開始インデックス番号を指定するためにRESET MASTER TO ステートメントが使用される場合、指定できる最大の数が最大整数値から2000000000に減少しました。 最大整数値が指定された場合、サーバーはこれ以上バイナリログファイルを作成できないため、 起動できませんでした。また、サーバーは以前にその状況でセグメンテーション違反も経験しました。 （Bug＃28980788、Bug＃28995220） ・レプリケーション：過負荷のサーバーでは、メンバーがグループに参加した時に、そのポイントを 示すVIEW_CHANGE_LOG_EVENTイベントが正しい場所に記録されていなかった可能性がありました。 これにより、新しく参加するサーバーへのデータ転送やデータの分岐でエラーが発生する可能性が ありました。現在、VIEW_CHANGE_LOG_EVENTイベントはバイナリログの正しい場所に記録されます。 さらに、イベントを記録する際の遅延について、警告が記録されます。（Bug #28971594） ・レプリケーション：GTIDが使用されていてバイナリロギングが無効になっている レプリケーションスレーブで、DDLステートメントがテーブルフィルターによって追放された時、 デバッグモードでアサーションが発生しました。（Bug＃28965972） ・レプリケーション：バイナリログ内のステートメントベースのレプリケーションイベントの デシリアライゼーションに関する2つの問題が修正されました。（Bug＃28889181、Bug＃29028491） ・レプリケーション：アプライヤスレッドがテーブルを開く処理中に停止した場合、エラーが 設定されなかったために、ビルドタイプによってセグメンテーションフォルトやアサーションが 発生する可能性がありました。エラー処理は、現在、この状況では正しく有効になります。 （Bug #28864557） ・レプリケーション：グループレプリケーション用のIPアドレスホワイトリスト （group_replication_ip_whitelist）にホスト名が指定された時、IPv4アドレスも使用可能な場合は IPv6アドレスが名前解決およびホワイトリスト比較に使用されました。IPv4アドレスは、常に グループレプリケーション接続に関して優先されるべきです。現在、ホスト名がIPv4アドレスに 解決される場合、IPv6アドレスはホワイトリストとの比較のために考慮されません。（Bug＃28841543） ・レプリケーション：サーバーでGTIDが使用される場合、マスターが自動スキップ機能を使用して トランザクションをスキップするたびに、レプリケーションスレーブ上のマスター情報ログが 同期されていました。プロセスは、スレーブに送信されてログへの強制フラッシュを引き起こした ダミーのハートビートで終了します。これは、スレーブの書き込み負荷に大きな累積的な影響を 与える可能性がありました。同じサーバーから発生しそのために無視されたイベントを含む 循環レプリケーショントポロジーでも、同じ問題が発生する可能性がありました。それらも、 ログへの強制フラッシュでスレーブによって処理されました。ハートビートイベントおよび 循環レプリケーションを介して受信された無視されたイベントに対する強制フラッシュを削除する ようにスレーブ処理コードが変更され、マスター情報ログが適切な場合（例：CHANGE MASTER ステートメントが発行された場合、またはバイナリログがローテーションされる場合）にのみ 同期されるようになりました。（Bug #28815555、Bug #85158） ・レプリケーション：ALTER TABLEステートメントが新しい列の式のデフォルト値を指定するために DEFAULT句とともに使用され、式のデフォルト値が非決定的関数を参照している場合、 そのステートメントはステートメントベースのレプリケーションに対して安全ではありません。 以前は、そのようなステートメントはGTIDの整合性の観点からも評価されていましたが、 GTIDの整合性には影響しないため、これは適切なチェックではありませんでした。現在、 これらのステートメントはバイナリロギングに対してのみ評価され、使用中の バイナリロギングフォーマットに応じて処理されます。binlog_formatがSTATEMENTに 設定されていると、ステートメントはログに記録されますが、警告メッセージはエラーログに 書き込まれます。binlog_formatがMIXEDまたはROWに設定されていると、ステートメントは 実行されず、エラーメッセージはエラーログに書き込まれます。（Bug＃28799939） ・レプリケーション：シングルプライマリモード（デフォルトである group_replication_single_primary_mode=ON）に設定されたレプリケーショングループでは、 深刻なネットワーク遅延がグループに影響を与えると、プライマリとセカンダリが トランザクションについて異なる決定を下す可能性があり、メンバーのgtid_executed設定に 相違が生じる可能性がありました。この問題は修正されました。 （Bug #28768550、Bug #28966455、Bug #92690） ・レプリケーション：以前は、FLUSH RELAY LOGSステートメントを使用して、グループレプリケーションの group_replication_applierチャネルに関してリレーログを手動でローテーションすることはできません でした。この制限により、MySQL 8.0.14以降で使用可能なバイナリログファイルおよび リレーログファイルに対して暗号化が有効になっている時に（binlog_encryption=ON）、 暗号化が再度無効にされた場合、そのチャネルで使用中のリレーログファイルはすぐに ローテーションできません。この制限は、バイナリログのマスターキーローテーションに MySQL 8.0.16から使用可能なものと同様の影響を与えました。現在この制限は削除され、 FLUSH RELAY LOGSステートメントとそれに対応する内部リクエストは現在他のチャネルと同様に group_replication_applierチャネルで動作します。ただし、トランザクションの適用中に リクエストが受信された場合、トランザクションの終了後にリクエストが実行されることを除きます。 トランザクションが完了してローテーションが行われるまで、リクエスターは待機する必要があります。 この動作により、グループレプリケーションでは許可されていないトランザクションの分割が回避 されます。 （Bug＃28684376） ・レプリケーション：group_replication_force_membersシステム変数を使用してグループの 新しい設定を強制する時、グループ通信エンジン（XCom）は、現在、あなたが現在到達不可能な グループメンバーを含まないことをチェックします。見つかった場合、再設定は許可されず、 エラーが返されます。（Bug＃28678845） ・レプリケーション：バイナリログに書き込まれたGRANTステートメントが誤ってログに記録される ことがあり、その結果、マスター上で正常に実行されたGRANTステートメントがレプリケーション スレーブ上でエラーを引き起こす可能性がありました。 （Bug #28643405、Bug #29155451、Bug #93750） ・レプリケーション：サーバー起動時にメンバーがグループに参加した時、例えばサーバーがグループと 互換性がないなどの理由で参加プロセスが失敗した場合、オフラインのメンバーは別のメンバーを オンラインであると見なす可能性がありました。現在、このような状況では、 performance_schema.replication_group_membersテーブルに表示される情報は、 ローカルメンバーがOFFLINEの時にはローカルメンバーに制限されます。（Bug＃28533993） ・レプリケーション：ストレージエンジンがSTATEMENT形式でログに記録する機能があり、ROW形式では できない場合、binlog_formatがSTATEMENTに設定されていると、安全でないSQLステートメントが ログに記録され、警告メッセージがエラーログに書き込まれます。ただし、 そのようなステートメントは実行されず、エラーメッセージはエラーログに書き込まれました。 これは、binlog_formatがMIXEDまたはROWに設定されている場合の正しい動作です。この問題は 現在修正され、binlog_formatがSTATEMENTに設定されている場合、安全でないステートメントは 期待どおりに警告とともにログに記録されるようになりました。（Bug #28429993、Bug #73936） ・レプリケーション：リカバリーチャネル障害が発生した場合、未処理のリレーログが消去されていました。 （Bug＃27940732） ・レプリケーション：レプリケーショングループのメンバーは、一時的にオフラインになってから、 そのグループが障害を検出してメンバーを削除するように再設定される前に再度 レプリケーショングループに参加しようとする可能性があります。以前は、この状況では、 再参加メンバーがクラッシュ前のインカネーション向けのメッセージを受信して処理した場合、 XComのコンセンサスプロトコルに参加することができました。これにより、 XComは同じコンセンサスラウンドに対して異なる値を提供する可能性があります。これは、 再参加メンバーが失敗の前後で異なる決定を下す可能性があるためです。この状況を回避するために、 再参加メンバーは現在クラッシュ前のインカネーション用のメッセージを無視するようになりました。 （Bug＃27383487） ・レプリケーション：レプリケーショングループのメンバーは、大多数の損失によりグループから 追放された後にローカルビューを起動することができました。この結果、メンバーが追放後に 通常の操作を再開したことを誤って記載したメッセージが表示されました。 グループレプリケーションは、現在、ローカルビューを配信する前に、メンバーが追放されていない ことを確認するようになりました。（Bug＃27349236） ・レプリケーション：group_replication_communication_debug_optionsシステム変数に無効な値が 指定された場合、グループ通信システムはそれに対応する内部変数をGCS_DEBUG_NONEに設定し、 サーバーはSHOW VARIABLESクエリに対して無効な値を返しました。現在、サーバー初期化中に システム変数の値がチェックされます。無効な値が指定された場合、エラーメッセージがログに 記録され、グループレプリケーションは自動的に開始されません。（Bug＃26729404） ・macOS：メイクファイルではなくXcodeでビルドする場合、現在CMake 3.12.4以降 （UseModernBuildSystem=NOを強制する）がmacOSでは必要です。（Bug＃28893131） ・Microsoft Windows：named_pipe_full_access_groupシステム変数の妥当性テストで、NULL値が 考慮されていませんでした。（Bug #29256690） ・Microsoft Windows：mysqldの複数のインスタンスが同一ユーザーの同一ホスト上で --no-monitorオプションを使用して起動された場合、SHUTDOWNコマンドで誤ったサーバープロセスが シャットダウンされました。この修正は、プロセスのプロセスIDを追加することによって --no-monitorで使用するための一意のシャットダウンイベント名を作成します。（Bug＃28723675） ・JSON：JSONパスパーサーは、現在、MySQLサーバーの他のほとんどのコンポーネントと同じ方法で エラーを伝え、エラーの時にはtrue、成功時にはfalseを返します。（Bug＃28851426） ・JSON：Json_wrapper::get_datetime()の不必要な型の検索を削除しました。（Bug＃28851324） ・authentication_ldap_simpleプラグインが誤って認証を強制する可能性がありました。 （Bug #29637712） ・RPMパッケージの廃止が更新され、EL8でMariaDBからMySQLへのアップグレードが成功するように なりました。（Bug＃29413354） ・外部結合の結果に、NULL拡張行が期待されるところにNULL以外の行が含まれる可能性がありました。 （Bug＃29402481） 参考：この問題はBug #27808758のレグレッションです。 ・SET PASSWORD FOR ...を準備文として実行できませんでした。（Bug＃29387041、Bug＃94416） ・MySQLルーターライブラリの構築中にVisual Studioでのビルドに失敗することがありました。 （Bug＃29382197） 参考：この問題はBug #29361890のレグレッションです。 ・インポートした外部キーは、参照先テーブルの前に定義した場合、機能しませんでした。 （Bug＃29379078、Bug＃94400） 参考：この問題はBug #28493257のレグレッションです。 ・解決時にLIKE式のESCAPE句を評価している間にエラーが発生した時、エラー状況は呼び出し元に 伝えられませんでした。（Bug＃29368521） ・innodb_table_stats_backupとinnodb_index_stats_backupのメタデータバックアップテーブルの テーブルスペースファイルは、MySQL 5.7からMySQL 8.0へのインプレースアップグレード後に 削除されませんでした。（Bug＃29365552） ・サブクエリをフラット化している間、常にfalseである述語が存在する場合、MySQLオプティマイザーは いかなる種類の変換も実行せず、その結果サブクエリは準備されず、それが後で実行された時にアサート しました。この問題を解決するために、そのような述語がサブクエリに存在する場合、サブクエリの クエリ式は現在クエリブロックからのリンクを解除されます。（Bug＃29356132） ・ALLOW_INVALID_DATES SQLモードでイベント、ルーチン、トリガが定義された場合、 MySQL 8.0.11、8.0.12、8.0.13からMySQL 8.0.14、8.0.15へのアップグレードは失敗しました。 データディクショナリのSQLモード識別子がMySQL 8.0.14で変更されたため、移行の失敗が 発生しました。（Bug＃29350955） ・RPMビルドは、WITH_SSL設定を無視しました。（Bug＃29347534） ・TO_SECONDS()関数の長さメタデータは必ずしも正しく計算されていませんでした。（Bug＃29321387） ・常に真か偽であるために削除されたウィンドウ関数を使った条件は、必ずしも正しく処理されて いませんでした。（Bug＃29320484） ・SET ROLEステートメントは、メモリリークを起こす可能性がありました。（Bug＃29304583） ・WindowsでのMySQL 5.7からMySQL 8.0へのアップグレードは、 “Error 197 from SE while migrating tablespaces”が原因で失敗しました。このエラーは、 テーブルスペースファイルを開こうとした時に発生したアクセス共有違反が原因でした。 （Bug＃29292860） 参考：この問題はBug #28642608のレグレッションです。 ・RPMパッケージでは、COMPILATION_COMMENT_SERVERの値が正しくない可能性がありました。 （Bug＃29284651） ・新しいテーブル定義にプライマリキーがなく、sql_require_primary_keyシステム変数が有効に なっている場合、テーブルがすでに存在していても、CREATE TABLE IF NOT EXISTSが失敗しました。 （Bug＃29283055、Bug＃94134） ・すべてのパーティションがプルーニングされたパーティションテーブルからの削除は、 必ずしも正しく処理されませんでした。 （Bug＃29280186） ・GNU goldリンカーのCMakeチェックは、Clangで失敗する可能性がありました。（Bug＃29278244） ・データディクショナリのバージョンが、MySQL 8.0.16リリースでインクリメントされました。 （Bug＃29278241） ・DISTINCTと共に使用されている関数に対する間違った型の引数は、必ずしも正しく処理されません でした。（Bug＃29277571） ・QUOTE()関数の長さメタデータは、必ずしも正しく計算されていませんでした。（Bug＃29276074） ・GREATEST()またはLEAST()を評価する時、MySQLはNULL戻り値にNULLがないかチェックする前に 戻り値の正当性をチェックしました。（Bug＃29275835） ・厳密なSQLモードが有効でなかった時、max_allowed_packetよりも大きい結果を示すためにNULLを返す 文字列関数の値は矛盾した動作として処理され、結果として誤ってソートされた出力やその他の 誤動作を引き起こす可能性がありました。（Bug＃29272683） 参考：Bug＃97301、Bug＃29133127。 ・特定のサーバーのバージョンへのアップグレードがサポートされているかどうかをチェックする ロジックは、アップグレードがサポートされていないサーバーバージョンをチェックするために 反転されました。（Bug＃29270297） ・イベント作成は誤った繰り返し間隔を保存する可能性がありました。（Bug＃29269819、Bug＃94085） ・ビュー参照や変換によって作成されたアイテムを含むWHERE条件は、必ずしも正しく処理されません でした。（Bug＃29268867、Bug＃29268698、Bug＃28723669、Bug＃29244238） ・mysql_ssl_rsa_setupは、GCC 9を使用したコンパイルに失敗しました。（Bug＃29245251） ・CMakeがMySQLで動作するには古すぎるlibtirpcライブラリを見つけた場合、代わりにglibcの Sun RPCを使おうとします。（Bug #29240701） ・サーバーは、クエリ実行時間の計算が誤っているため、スロークエリログへのスロークエリの 書き込みに失敗する可能性がありました。（Bug＃29232684、Bug＃93963） ・位置を使用したMySQL正規表現関数は、コードポイント位置ではなく、16ビットチャンクに基づく 内部インデックスを使用しました。（Bug＃29231490） ・Windowsでは、MySQL MSIインストーラーはVisual Studio 2015 Redistributableが インストールされているかどうかを正しく検出できないことがありました。（Bug＃29227209） ・SDI JSONファイルにIndex_implオブジェクトのm_hiddenフィールドが含まれていませんでした。 これにより、InnoDBはいくつかの隠しインデックスを追加するため、SDI JSONを使用して テーブルのCREATEステートメントを再作成することは困難でした。SDI JSONには、現在、 m_hiddenフィールドが含まれます。これはSDIフォーマットを変更するので、SDIのバージョン番号は 現在のサーバーバージョン番号に増加しました。（Bug＃29210646、Bug＃93914） ・範囲枠内の最終行の位置ヒントが、その枠内の実際の最終行から1行後に更新されました。 （Bug＃29201831） ・列の定義において、複数の制約定義は、最初のものがCHECK制約の場合、受け付けられませんでした。 （Bug＃29191994） ・サーバーがバージョンアップを実行している場合、起動中にバッファリングされたエラーログ情報が長く バッファリングされ過ぎる可能性がありました。（Bug＃29189532） ・NULLが許可された列に関して、その列がNULLの場合を除いて常に真になる式を見つけた場合、その式は column IS NOT NULLに畳み込まれます。このような式がネストされていると、NULL行が誤って 選択されていました。これが起こらないようにするために、ネストされた時のそのような式は、現在、 代わりにIF(column IS NULL, NULL, TRUE)に畳み込まれます。（Bug＃29179604） ・Windowsプラットフォームで、PERIOD_ADD()はperiod引数の長さが32ビットを超える値を正しく処理 しませんでした。（Bug＃29175262） ・sql_auto_is_nullが有効になっていると、WHERE auto_increment_col IS NULL形式のWHERE句は、 WHERE auto_increment_col=LAST_INSERT_ID()に書き換えられます。この変換は、 自動インクリメントされた値ごとに1回だけ実行されたため、変換が実行されるかどうかを事前に 知ることは困難でした。現在、sql_auto_is_nullが有効になっている時はいつでも、変換が 無条件に実行されます。さらに、現在、LAST_INSERT_ID()によって返される値は符号なしとして 扱われるようになり、符号付きのBIGINTの範囲外の自動インクリメントされた値と一致しないという 問題は修正されました。（Bug＃29171668） ・DebianおよびUbuntuでは、非対話モードでのインストール操作はrootのパスワードを無視しました。 その結果、デフォルトでauth_socket認証プラグインがインストールされていました。（Bug＃29165407） ・harness_plugin_eventlog宣言により、一部のビルド環境でコンパイルエラーが発生しました。 （Bug＃29160214） ・定数の畳み込み中に10進定数を希望の小数桁数に切り捨てたり拡張したりするロジックが欠けていました。 拡大の決定は小数桁の合計数ではなく、ゼロ以外の小数桁数に基づいているため、小数内の余分な末尾の ゼロは小数を拡大する試みを引き起こす可能性があり、内部関数widen_fraction()での （デバッグビルドでの）アサートにつながります。この問題は、単に余分な末尾のゼロを切り捨てる 可能性がある場合を識別することによって修正されています。この場合、比較演算子を調整する必要は なく、代わりに定数を末尾のゼロの数が少ないものに置き換えることができます。（Bug＃29155439） ・Windowsでは、内部関数get_mysql_time_from_str_no_warn()が常に正しいエラーチェックをしている わけではありませんでした。（Bug＃29155126） 参照：Bug #29175262。 ・特定の条件下では、同じテーブルの名前を複数回変更したRENAME TABLEステートメントは、 アサーションを発生させたり、サーバーを終了させたりする可能性がありました。（Bug＃29140407） ・デバッグビルドでは、--event-scheduler=DISABLEDでサーバーを起動すると、特定のイベントに 対してアサーションが発生する可能性がありました。（Bug＃29140298、Bug＃93719） ・デバッグビルドでは、厳格なSQLモードが有効でなかった時、結果がmax_allowed_packetよりも 長かった場合、CONCAT()関数とCONCAT_WS()関数はアサーションを起こしました。（Bug＃29133127） ・範囲外の小数部分は、SET SESSION timestampステートメントに誤ったタイムスタンプを生成する 可能性がありました。（Bug＃29120569、Bug＃93600） ・mysql_service_component_sys_variableサービスは、コンポーネントのシステム変数にアクセス できましたが、サーバーやプラグインのシステム変数にはアクセスできませんでした。（Bug＃29113463） ・ALTER TABLE ... CONVERT TO CHARACTER SETは、メモリアクセスエラーを起こす可能性がありました。 （Bug＃29058369、Bug＃93603） ・mysql.tablespaces.name列の制限は、259バイトであり、許可された識別子の長さに必要な長さを 下回っていました。列の制限は268バイトに引き上げられました。（Bug＃29053560、Bug＃93587） ・デバッグビルドに関して、アサーションを発生させた空間計算の場合、パーティション処理コードは エラーを無視し、その結果サーバーは終了しました。 （Bug＃29047811） ・外部に格納された長さ0のLOBが、アサーション失敗を引き起こしました。（Bug＃29047795） ・COMPILE_DEFINITIONSとCOMPILE_FLAGSのCMakeオプションの処理は、クロスコンパイルの失敗を 避けるために調整されました。（Bug＃29041100） ・max_error_countシステム変数が0に設定されていても、サーバーは最初の診断領域メッセージを 読み込もうとしたため、結果としてメモリアクセスエラーとなりました。（Bug＃29031684） ・DATE値と定数文字列を比較する時、MySQLはまず文字列をDATEに変換してから比較を実行しようと します。変換に失敗した場合、MySQLはDATEを文字列として扱い比較を実行しました。これは 予期しない動作につながる可能性がありました。現在、そのような場合、文字列からDATEへの変換が 失敗すると、比較はER_WRONG_VALUEで失敗します。（Bug＃29025656） ・--usersオプションを使用すると、mysqlpumpはCREATE USERステートメントとGRANTステートメント を出力に書き出しましたが、ダンプによって作成された他のオブジェクトに適用するには遅すぎ ました。その結果、ダンプファイルを復元すると、ユーザーアカウントがあまりにも遅く作成され、 ファイルによって作成された他のオブジェクトに適用できませんでした。mysqlpumpは、現在、 他のオブジェクトよりも先にダンプファイルにユーザーアカウントを書き込みます。（Bug #29023216）
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.16リリースノート（MySQLウェブサイト）：
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-16.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。