重要
MySQL Installerを使用してインストールされたMySQL 8.0.19には、サーバー設定段階でMySQL Enterprise Firewallが選択された場合にサーバーが起動しないという問題があります。サーバーの起動操作が失敗した場合、キャンセルをクリックして設定プロセスを終了し、ダッシュボードに戻ります。サーバーをアンインストールする必要があります。
回避策は、MySQL Enterprise Firewallを選択せず??にMySQL Installerを実行することです。その後、手動インストールの手順に従ってMySQL Enterprise Firewallをインストールします。この問題は、MySQL 8.0.20で修正されます。
主な変更点
■ Account Management関連
● MySQLでは、現在、管理者は、不正なパスワードによる連続したログイン失敗が多すぎると一時的にアカウントロックがかかるといったユーザーアカウントの設定をできます。 必要な失敗回数とロック時間は、CREATE USERとALTER USERステートメントのオプションであるFAILED_LOGIN_ATTEMPTSとPASSWORD_LOCK_TIMEを使用して、アカウントごとに設定可能です。（Bug #27733694, Bug #90169）
■ 監査ログ関連
● ANALYZE TABLEステートメントは、現在、読み取り監査イベントを生成します。 （Bug #29625461） ● 監査ログ接続イベントには、現在、クライアントによって渡された接続属性が含まれます。 接続属性ロギングは、新しいスタイルのXMLログファイル形式とJSON形式でサポートされていますが、古いスタイルのXML形式ではサポートされていません。
■ コンパイル関連
● Microsoft Windows：Windowsでは、コマンドラインからビルドするためのCMakeの最小バージョンは現在3.15です。（Bug #30332632, Bug #96954）
■ 設定関連
● 新しいFPROFILE_GENERATEおよびFPROFILE_USE CMakeオプションは、GCCを使用したプロファイルに基づく最適化（PGO）の検証作業に使用できます。これらのオプションは、GCC 8と9、およびClangでテストされています。 FPROFILE_USEを有効にすると、WITH_LTO（リンク時間の最適化）も有効になります。（Bug #30089834, Bug #96314, Bug #30133324, Bug #96410, Bug #30164113, Bug #96486） ● ステータス変数Innodb_system_rows_read、Innodb_system_rows_inserted、Innodb_system_rows_deletedが、システムが作成したスキーマに属するInnoDBテーブルでの行操作をカウントするために追加されました。これらの新しいステータス変数は、ユーザーが作成したスキーマとシステムが作成したスキーマの両方に属するInnoDBテーブルでの操作をカウントする既存のステータス変数Innodb_rows_read、Innodb_rows_inserted、Innodb_rows_deletedに類似しています。 この新しいステータス変数は、relay_log_info_repository変数とmaster_info_repository変数がTABLEに設定されたレプリケーション環境で役に立ちます。結果として、システムで作成されたmysqlスキーマに属するテーブルslave_master_info、slave_replay_log_info、slave_worker_infoで実行される操作により、スレーブでの行操作カウントが増加します。マスターとスレーブの行操作カウントの有効な比較のために、システムが作成したスキーマのテーブルでの操作は、新しいステータス変数によって提供されるカウントデータを使用して、除外されることが可能になりました。 （Bug #27724674）
■ 非推奨と削除
● hash_joinオプティマイザスイッチの設定は、今はもう効力がありません。オプティマイザーヒントHASH_JOINとNO_HASH_JOINに関しても同じことが当てはまります。オプティマイザースイッチとオプティマイザーヒントの両方が非推奨になり、MySQLの将来のリリースで削除される可能性があります。（Bug #30471809） ● YEAR(2)データ型のサポートはMySQL 5.7.5で削除され、YEARとYEAR(4)のみが年値データの有効な仕様として残されました。YEARとYEAR(4)は意味的に同一であるため、表示幅の指定は必要ありません。そのため、YEAR(4)は現在非推奨になり、将来のMySQLバージョンではサポートが削除されるでしょう。それらの出力にデータ型定義を含むステートメントは、今はもうYEARの表示幅を表示しません。この変更はテーブル、ビュー、ストアドルーチンに適用され、SHOW CREATEステートメントとDESCRIBEステートメントからの出力、およびINFORMATION_SCHEMAテーブルからの出力に影響します。 DESCRIBEステートメントとINFORMATION_SCHEMAクエリの場合、データディクショナリに既に保存されている情報は変更されないままであるため、以前のMySQL 8.0バージョンで作成されたオブジェクトの出力は影響を受けません。この例外は、MySQL 5.7から8.0へのアップグレードには適用されません。それに対しては、データ型定義に表示幅が含まれないように、すべてのデータディクショナリ情報が再作成されます。 YEARの（文書化されていない）UNSIGNED属性も非推奨になり、将来のMySQLバージョンでサポートが削除されるでしょう。
■ エラー処理
● XAのクラッシュリカバリに関するエラーメッセージは、非XAクラッシュリカバリメッセージと区別するためにXAコンテキストを示すように修正されました。（Bug #30578290, Bug #97743） ● 以前、サーバーは、LOCAL機能を無効にしてLOAD DATA LOCALを使用しようとすると、次のエラーメッセージを返しました： The used command is not allowed with this MySQL version.（使用されたコマンドは、このMySQLバージョンでは許可されていません。） エラー状態はMySQLバージョンに関連していないため、これは誤解を招くものでした。サーバーは、現在、ER_CLIENT_LOCAL_FILES_DISABLEDのエラーコードと次のメッセージを返します： Loading local data is disabled; this must be enabled on both the client and server side.（ローカルデータのロードは無効です。これは、クライアント側とサーバー側の両方で有効にする必要があります。） （Bug #30375698, Bug #29377985, Bug #94396）
■ 関数とオペレータ関連
● 以前は、ユーザー定義関数（UDF）は文字セットまたは文字列引数の照合または戻り値の照合を考慮していませんでした。実際には、文字列引数と戻り値はバイナリ文字列として扱われ、シングルバイト文字を含む文字列引数のみが確実に処理され得るということを意味していました。 デフォルトではUDFの動作は今も同じですが、UDFを記述するためのインターフェイスが拡張され、UDFが文字セットと文字列引数の照合を決定し、特定の文字セットと照合を持つ文字列を返すことができるようになりました。これらの機能は、UDFライターのオプションであり、必要に応じて利用できます。 MySQLとともに配布されるUDFのうち、次の機能と拡張機能に関連するものは、新しい機能を利用するために修正されました：MySQL Enterprise Audit、MySQL Enterprise Firewall、MySQL Enterprise Data Masking and De-Identification、MySQL Keyring（汎用キーリングUDFのみ）、Group Replication。この修正は、意味がある場合にのみ適用されます。例えば、暗号化されたデータを返すUDFは、文字の文字列ではなくバイナリの文字列を返すことを目的としています。 UDFの文字セット機能は、mysql_udf_metadataサーバーコンポーネントサービスを使用して実装されます。このサービスの詳細については、https：//dev.mysql.com/doc/index-other.htmlで入手可能なMySQL Server Doxygenのドキュメントを参照してください（s_mysql_mysql_udf_metadataとudf_metadata_impを検索してください）。MySQL Keyring UDFのソースコードはコミュニティソースディストリビューションで入手可能で、独自のUDFを文字セット対応に変更したいサードパーティUDFライターのための例として検討できます。
■ INFORMATION_SCHEMA関連
● INFORMATION_SCHEMAには、ロール情報を公開するいくつかの新しいテーブルが含まれています。 ・ADMINISTRABLE_ROLE_AUTHORIZATIONS: 現在のユーザーが付与できるロール; INFORMATION_SCHEMA ADMINISTRABLE_ROLE_AUTHORIZATIONSテーブルを参照。 ・APPLICABLE_ROLES: 現在のユーザーに適用可能なロール。 ・ENABLED_ROLES: 現在のセッション内で有効なロール。 ・ROLE_COLUMN_GRANTS: 現在のユーザーのロールの列権限。 ・ROLE_ROUTINE_GRANTS: 現在のユーザーのロールのルーチン権限。 ・ROLE_TABLE_GRANTS: 現在のユーザーのロールのテーブル権限。
■ キーリング関連
● MySQLキーリングを使用した機密データの汎用ストレージ用の新しいSECRETキータイプが利用可能です。キーリングは、保管および取得時にSECRETデータをバイトストリームとして暗号化および復号化します。SECRETキータイプは、すべてのキーリングプラグインでサポートされています。
■ ロギング関連
● SIGUSR1シグナルにより、サーバーはエラーログ、一般クエリログ、スロークエリログをフラッシュするようになりました。SIGUSR1の用途の1つは、サーバーに接続することなくログローテーションを実装することです（ログをフラッシュするためには、RELOAD権限を持つアカウントが必要です）。SIGUSR1へのサーバー応答は、SIGHUPに対する応答のサブセットであり、SIGUSR1を他のSIGHUP効果なしで特定のログをフラッシュするもっと"軽量"なシグナルとして使用できるようにします。例えば、スレッドとホストキャッシュのフラッシュ、エラーログへのステータスレポートの書き込みなど。
■ パッケージング関連
● MySQLにバンドルされているzstdライブラリがバージョン1.3.3から1.4.3にアップグレードされました。MySQLはzstdライブラリを使用して接続の圧縮をサポートします。（Bug #30236685） ● OpenSSL共有ライブラリが含まれるパッケージタイプに関しては、OpenSSLを必要とするlib/privateにあるprivate-to-MySQLライブラリがパッケージにある場合、それらはlib/privateにも含まれるようになりました。（Bug #29966296）
■ SQL構文関連
● 重要な変更：MySQLは、現在、SQL標準に従って明示的なテーブル句とテーブル値コンストラクタをサポートしています。
これらは、それぞれ、TABLEステートメントとVALUESステートメントとして実装されました。それぞれについて簡単に説明します。
・TABLE table_nameは、SELECT * FROM table_nameと同等であり、同等のSELECTステートメントが受け入れられる場所であればどこでも使用できます。これには、join、union、INSERT ... SELECTステートメント、REPLACEステートメント、CREATE TABLE ... SELECTステートメント、サブクエリが含まれます。
TABLEと共にORDER BYを使用できます。これは、オプションのOFFSETを使用するLIMITもサポートします。これらの句は、SELECTを使用する場合と同じようにTABLEステートメントで機能します。。次の2つのステートメントは同じ結果を生成します。
TABLE t ORDER BY c LIMIT 10 OFFSET 3;
SELECT * FROM t ORDER BY c LIMIT 10 OFFSET 3;
・VALUESは、VALUESキーワードと、それに続くコンマで区切られた一連の行コンストラクター（ROW()）で構成されます。それは、SQLに準拠した方法でINSERTステートメントまたはREPLACEステートメントに行の値を提供するために使用できます。例えば、次の2つのステートメントは同等です。
INSERT INTO t1 VALUES ROW(1,2,3), ROW(4,5,6), ROW(7,8,9);
INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9);
・テーブルの場合と同様に、VALUESテーブル値コンストラクターから選択することもできます。その際、テーブルエイリアスを提供する必要があることに注意してください。列エイリアスを使用して、次のように個々の列を選択することも可能です。
mysql> SELECT a,c FROM (VALUES ROW(1,2,3), ROW(4,5,6)) AS t(a,b,c);
+---+---+
| a | c |
+---+---+
| 1 | 3 |
| 4 | 6 |
+---+---+
このようなSELECTステートメントは、このようなステートメントを使用できると通常予想されるjoin、union、サブクエリ、その他の構成で使用できます。
（Bug #77639）
● 以前は、再帰共通テーブル式（CTE）の再帰SELECT部分でLIMITを使用することはできませんでした。そのような場合、LIMITはオプションのOFFSET句を伴うことでサポートされるようになりました。そのような再帰CTEの例を次に示します。
WITH RECURSIVE cte AS (
SELECT CAST("x" AS CHAR(100)) AS a FROM DUAL
UNION ALL
SELECT CONCAT("x",cte.a) FROM qn
WHERE LENGTH(cte.a) < 10
LIMIT 3 OFFSET 2;
)
SELECT * FROM cte;
この方法でLIMITを指定すると、要求された行数のみが生成されるため、最も外側のSELECTでそれを行うよりもより効率的にCTEを実行できます。
（Bug #92857, Bug #28816906）
● チェック制約がMySQL 8.0.16に実装された時、ALTER TABLEはチェック制約を変更するための標準SQLのMySQL拡張としてDROP CHECKおよびALTER CHECK構文をサポートしましたが、任意のタイプの既存の制約を変更するためのより一般的な（かつSQL標準の）DROP CONSTRAINTおよびALTER CONSTRAINT構文をサポートしませんでした。その構文は現在サポートされています。制約タイプは制約名から決定されます。
● MySQLは、挿入される行とその列に関してINSERT INTO ... ON DUPLICATE KEY UPDATEステートメントのVALUES句とSET句でエイリアスをサポートするようになりました。次のようなステートメントを検討してください。
INSERT INTO t
VALUES (9,5), (7,7), (11,-1)
ON DUPLICATE KEY UPDATE a = a + VALUES(a) - VALUES(b);
挿入された行に新しいエイリアスを使用すると、次のように、ON DUPLICATE KEY UPDATE句で行エイリアスを参照しなおし、ステートメントを書き換えることができます。
INSERT INTO t
VALUES (9,5), (7,7), (11,-1) AS new
ON DUPLICATE KEY UPDATE a = a + new.a - new.b;
同じ行エイリアスを使用して、さらに、挿入された行の列に列エイリアスmとnを使用すると、次のように、行エイリアスを省略して列エイリアスのみを使用できます。
INSERT INTO t
VALUES (9,5), (7,7), (11,-1) AS new(m,n)
ON DUPLICATE KEY UPDATE a = a + m - n;
行エイリアスはテーブル名とは異なるものでなければなりません。列のエイリアスは互いに異なるものでなければなりません。
■ sysスキーマ関連
● sysスキーマオブジェクトは、廃止されたストアド関数sys.format_bytes()、sys.format_time()、sys.ps_thread_id()を呼び出さないように再実装されました。代わりに、MySQL 8.0.16に実装された、パフォーマンススキーマデータをフォーマットまたは取得する同等の組み込みSQL関数を呼び出します。 sys.format_bytes()、sys.format_time()、sys.ps_thread_id()は、将来のMySQLバージョンで削除される予定です。そのため、それらを使用するアプリケーションは、sys関数と組み込み関数との間のわずかな違いに留意して、代わりに組み込み関数を使用するように調整される必要があります。
■ スレッドプール関連
● デフォルトでは、スレッドプールプラグインは、常に各グループで最大1つのスレッドの実行を確保しようとします。デフォルトのアルゴリズムでは、停止したスレッドが考慮され、より多くのアクティブなスレッドが一時的に許可される場合があります。プラグインは、現在、グループごとのアクティブなスレッドの数を制御するための新しいシステム変数thread_pool_max_active_query_threadsを実装しています。thread_pool_max_active_query_threadsが0の場合、デフォルトのアルゴリズムが適用されます。thread_pool_max_active_query_threadsが0より大きい場合、グループごとのアクティブスレッドの数に制限が設定されます。
■ Xプラグイン関連
● GCC 9を使用するDebianでは、Xプラグインをコンパイルできませんでした。問題の回避策を提供するために、--no-as-neededリンカーオプションが追加されました。（Bug #30445201） ● Xプロトコルを使用して情報スキーマテーブルのTRIGGERSに問い合わせを行うと、エラーが返されるか、一部の行が返されないという結果になる可能性がありました。（Bug #30318917） ● MySQL 5.7.14では、mysqlxの名前空間パラメーターがXプロトコルのStmtExecuteリクエストのために導入され、xpluginのパラメーターが置き換えられました。そのため、xpluginパラメーターは非推奨となりました。Xプラグインは、下位互換性のために非推奨のxpluginの名前空間を引き続きサポートしました。MySQL 8.0.19では、xplugin名前空間が削除されました。このリリースからxpluginの名前空間が使用される場合、不明な名前空間に関してエラーメッセージが返されます。xpluginの名前空間に対して受信したStmtExecuteリクエストの数をカウントするXプラグインのステータス変数Mysqlx_stmt_execute_xpluginは、MySQL 8.0.19から使用されなくなりました。
■ 追加・変更された機能
● Microsoft Windows：以前は、mysqlコマンドラインクライアントのsystem (\!)コマンドはUnixシステムでのみ機能していました。現在はWindowsでも同様に動作します。例えば、system cls または \! clsは、画面をクリアするために使用できます。（バグ＃11765690、バグ＃58680） ● JSON：JSON_SCHEMA_VALID()を使用して1つ以上のJSON列を含むテーブルでCHECK制約を指定し、検証エラーが発生した場合、MySQLは現在そのようなエラーの理由に関する詳細情報を提供します。この情報を含む新しいエラーER_JSON_SCHEMA_VALIDATION_ERROR_WITH_DETAILED_REPORTが実装されています。これはサーバーによってINSERTステートメントが拒否された時にSHOW WARNINGSを発行することによってmysqlクライアントに表示できます。 ● 整数データ型の表示幅の指定はMySQL 8.0.17で非推奨になり、出力にデータ型定義を含むステートメントは現在整数型の表示幅を表示しませんが、次の例外があります。 ・型はTINYINT(1)です。MySQLコネクタは、TINYINT(1)の列がBOOLEAN列として作成されたと仮定します。この例外により、MySQLコネクタはその仮定を継続することができます。 ・型にはZEROFILL属性が含まれます。 この変更はテーブル、ビュー、ストアドルーチンに適用され、SHOW CREATEとDESCRIBEステートメントからの出力とINFORMATION_SCHEMAテーブルからの出力に影響します。 DESCRIBEステートメントとINFORMATION_SCHEMAクエリの場合、データディクショナリに既に保存されている情報は変更されないままのため、出力は以前のMySQL 8.0バージョンで作成されたオブジェクトに関して影響を受けません。この例外は、MySQL 5.7から8.0へのアップグレードには適用されません。そのために、データ型定義に表示幅が含まれないように、すべてのデータディクショナリ情報が再作成されます。（Bug #30556657, Bug #97680） ● レプリケーションスレーブへのレプリケーション接続、および、分散リカバリ用のグループレプリケーション接続には、現在TLSv1.3プロトコル用の完全なクライアント側設定オプションがあります。TLSv1.3サポートは利用できたが、これらの設定オプションは利用できなかったMySQLリリースでは、TLSv1.3がこれらの接続タイプに使用された場合、接続のクライアント（レプリケーションスレーブまたは分散リカバリを開始したグループレプリケーション参加メンバー）の設定はできませんでした。つまり、接続内のサーバー（レプリケーションマスタまたは分散リカバリ用のドナーであったグループレプリケーションの既存メンバー）は、デフォルトで有効になっている少なくとも1つのTLSv1.3暗号スイートの使用を許可する必要がありました。MySQL 8.0.19からは、この設定オプションを使用して、必要に応じてデフォルト以外の暗号スイートのみを含む、これらの接続の暗号スイートの選択を指定できます。 新しい設定オプションは次のとおりです。 ・グループレプリケーションシステム変数group_replication_recovery_tls_versionとgroup_replication_recovery_tls_ciphersuites。group_replication_recovery_tls_versionは、分散リカバリ接続のクライアントインスタンス（参加メンバー）の接続暗号化に許可されたTLSプロトコルのリストを指定します。group_replication_recovery_tls_ciphersuitesは、TLSv1.3がその接続に使用される場合に許可される暗号スイートのリストを指定します。 ・CHANGE MASTER TOコマンドのMASTER_TLS_CIPHERSUITESオプション。レプリケーションマスターへの接続のためにレプリケーションスレーブによって許可されたTLSv1.3暗号スイートのリストを指定します。（CHANGE MASTER TOコマンドには、接続に許可されたTLSプロトコルバージョンを指定するためのMASTER_TLS_VERSIONオプションが既にありました。） （Bug #29960735） ● Debianパッケージには、現在、手動のmysqld実行をより良くサポートする、より一般的なsystemdサポートが含まれています。（Bug #29702050, Bug #95163） ● グループレプリケーションプラグインは、SQL API操作を実行するために、内部セッションを使用してMySQL Serverとやりとりします。以前は、これらのセッションはmax_connectionsサーバーシステム変数で指定されたクライアント接続制限にカウントされていました。グループレプリケーションが開始される時または操作を実行しようとする時にサーバーがこの制限に達した場合、操作は失敗し、グループレプリケーションまたはサーバー自体が停止する可能性がありました。MySQL 8.0.19から、グループレプリケーションとMySQL Serverとのやりとりは、内部セッションを個別に処理する新しいコンポーネントサービスを使用します。つまり、max_connectionsの制限にはカウントされず、サーバーがこの制限に達しても拒否されません。（Bug #29635001） ● 重複キーエラー情報が拡張され、キーのテーブル名が含まれるようになりました。以前は、重複キーエラー情報にはキー値とキー名のみが含まれていました。（Bug #28686224, Bug #925308） ● mysqlクライアントがインタラクティブモードで動作する時、--binary-as-hexオプションは現在デフォルトで有効になります。さらに、オプションが暗黙的または明示的に有効になっている場合、status（または\s）コマンドからの出力には次の行が含まれます。 Binary data as: Hexadecimal 16進表記を無効にするためには、--skip-binary-as-hexを使用します。（Bug #24432545） ● MySQLは、現在、'2019-12-11 10:40:30-05:00'、'2003-04-14 03:30:00+10:00'、'2020-01-01 15:35:45+05:30'などのタイムゾーンオフセット付きの日時リテラルをサポートしています。これらのオフセットは、そのような値をTIMESTAMPやDATETIME列に挿入する時、尊重されますが保存されません。つまり、値を取得する時にオフセットは表示されません。 タイムゾーンオフセットでサポートされる範囲は、-14:00から+14:00までです。特別な値'SYSTEM'を含む、'CET'や'America/Argentina/Buenos_Aires'などのタイムゾーン名は、日時リテラルではサポートされていません。さらに、このコンテキストでは、10未満の時間値には先頭にゼロが必要であり、MySQLはオフセット'-00:00'を無効として拒否します。 タイムゾーンオフセット付きの日時リテラルも、準備済みステートメントのパラメーター値として使用できます。 この作業の一部として、time_zoneシステム変数の数値の許容範囲が変更され、それも-14:00から+14:00までになりました。 （Bug #83852, Bug #25108148） ● MySQL 8.0.19から、Xプロトコル接続を介して送信されるメッセージの圧縮がサポートされています。サーバーとクライアントが使用する圧縮アルゴリズムに同意する場合、接続を圧縮できます。デフォルトで、Xプロトコルはdeflate、lz4、zstdの圧縮アルゴリズムのサポートを発表しています。新しいシステム変数mysqlx_compression_algorithmsを設定することにより、これらのアルゴリズムを禁止して、許可したアルゴリズムのみを含めることができます。クライアントが機能のネゴシエーション中に圧縮を要求しない場合、Xプロトコルは常に非圧縮接続を許可します。Xプロトコルの許可された圧縮アルゴリズムのリストは、MySQL Serverによって発表された圧縮アルゴリズムのリストとは無関係に動作し、XプロトコルはMySQL Serverの圧縮設定の使用にフォールバックしないことに注意してください。新しいXプラグインステータス変数を使用して、Xプロトコルのメッセージ圧縮の効果を監視できます。 ● マルチスレッドスレーブ（slave_parallel_workersが0より大きい値に設定されているレプリケーションスレーブ）の場合、slave_preserve_commit_order=1を設定すると、トランザクションはスレーブのリレーログに表示される順序と同じ順序でスレーブで実行およびコミットされ、マスターと同じトランザクション履歴をスレーブで保持します。以前、この設定は、バイナリロギングとスレーブ更新ロギングをスレーブ上で有効にする必要があり、それに関連する実行コストとディスクスペース要件がありました。現在、slave_preserve_commit_order=1は、バイナリログとスレーブ更新ロギングなしでスレーブで設定できます。これにより、バイナリロギングのオーバーヘッドなしで、スレーブのコミット順序を保持し、トランザクションのシーケンスのギャップを回避できます。 ステートメントベースのレプリケーションが使用されており、トランザクションと非トランザクションのストレージエンジンの両方がマスターでロールバックされる非XAトランザクションに参加している場合、スレーブでコミット順序を保持する制限が発生する可能性があります。通常、マスターでロールバックされる非XAトランザクションはスレーブにレプリケートされませんが、この特定の状況では、トランザクションがスレーブにレプリケートされる場合があります。これが発生した場合、バイナリロギングなしのマルチスレッドスレーブはトランザクションのロールバックを処理しないため、その場合スレーブのコミット順序はトランザクションのリレーログ順序とは異なります。 ● MySQL 8.0.18リリースでは、レプリケーションチャネルにPRIVILEGE_CHECKS_USERアカウントを指定する機能が導入されました（CHANGE MASTER TOステートメントを使用）。それは、MySQLがレプリケートされたトランザクションが適用される時に権限チェックを行う対象となります。PRIVILEGE_CHECKS_USERアカウントの使用は、権限操作または不要な操作の不正使用または偶然の使用からレプリケーションチャネルを保護するのに役立ちます。レプリケーションチャネルが権限チェックで保護されている場合、行ベースのバイナリログの使用を強くお勧めします。 MySQL 8.0.19では、レプリケーションチャネル用に新しい設定REQUIRE_ROW_FORMATが追加されました。これにより、そのチャネルは行ベースのレプリケーションイベントのみを受け入れます。CHANGE MASTER TOステートメントを使用してREQUIRE_ROW_FORMATを指定すると、権限チェックで保護されているレプリケーションチャネルに行ベースのバイナリロギングを強制したり、この方法で保護されていないチャネルのセキュリティを強化したりできます。行ベースのレプリケーションイベントのみを許可することにより、REQUIRE_ROW_FORMATは、レプリケーションアプライヤーが一時テーブルの作成やLOAD DATA INFILEリクエストの実行などのアクションを実行することを防ぎ、既知の攻撃ベクトルからレプリケーションチャネルを保護します。行ベースのバイナリロギング（binlog_format=ROW）は、REQUIRE_ROW_FORMATが設定されている時、レプリケーションマスターで使用されなければなりません。 グループレプリケーションは既に行ベースのバイナリロギングを必要としているため、MySQL 8.0.19から、グループレプリケーションのチャネルはREQUIRE_ROW_FORMATセットで自動的に作成され、これらのチャネルのオプションを変更することはできません。この設定は、アップグレード時にすべてのグループレプリケーションチャネルにも適用されます。 mysqlbinlogには新しい--require-row-formatオプションがあり、これはmysqlbinlogの出力に対して行ベースのレプリケーションイベントを強制します。このオプションを使用して生成されたイベントのストリームは、REQUIRE_ROW_FORMATオプションを使用して保護されたレプリケーションチャネルによって受け入れられます。 ● MySQLは、テーブルパーティションのテーブルスペース名とファイル名を構築する時に区切り文字列を使用します。次に示すように、“#p#”区切り文字列がパーティション名の前にあり、“#sp#”区切り文字列がサブパーティション名の前にあります。 schema_name.table_name#p#partition_name#sp#subpartition_name table_name#p#partition_name#sp#subpartition_name.ibd 歴史的に、区切り文字列は、Linuxなどの大文字と小文字を区別するファイルシステムでは大文字（#P#と#SP#）であり、Windowsなどの大文字と小文字を区別しないファイルシステムでは小文字（#p#と#sp#）でした。大文字と小文字を区別するファイルシステムと大文字と小文字を区別しないファイルシステムの間でデータディレクトリを移行する時の問題を回避するために、現在はすべてのファイルシステムで区切り文字列が小文字です。大文字の区切り文字列は使用されなくなりました。 さらに、大文字と小文字で指定できるユーザー指定のパーティション名またはサブパーティション名に基づいて生成されるパーティションテーブルスペース名とファイル名は、現在、大文字と小文字を区別しないようにするためにlower_case_table_names設定に関係なく小文字で生成（かつ内部的に保存）されます。例えば、PART_1という名前でテーブルパーティションが作成された場合、そのテーブルスペース名とファイル名は小文字で生成されます。 schema_name.table_name#p#part_1 table_name#p#part_1.ibd アップグレード中、MySQLは必要に応じてチェックや変更を行うようになりました。 ・小文字の区切り文字とパーティション名を確保するためのディスク上およびデータディクショナリ内のパーティションファイル名。 ・以前のバグ修正で導入された関連問題のデータディクショナリ内のパーティションメタデータ。 ・以前のバグ修正で導入された関連問題のInnoDB統計データ。 テーブルスペースのインポート操作中、ディスク上のパーティションテーブルスペースファイル名は、小文字の区切り文字とパーティション名を確保するために、必要に応じてチェックされたり変更されます。 参照：Bug #26925260、Bug #29823032、Bug #30012621、Bug #29426720、Bug #30024653。 ● ヒストグラム統計を生成する目的で、InnoDBデータの効率的なサンプリングのサポートが追加されました。 ストレージエンジンが独自に提供しない時にMySQLが使用するデフォルトのサンプリング実装はフルテーブルスキャンを必要としますが、大きなテーブルではコストがかかります。InnoDBのサンプリング実装は、フルテーブルスキャンを回避することにより、サンプリングのパフォーマンスを向上させます。sampled_pa??ges_readとsampled_pa??ges_skippedのINNODB_METRICSカウンターを使用して、InnoDBデータページのサンプリングを監視できます。
■ 主なバグ修正
● 重要な変更：次の文字列関数の文字セットの解像度が変更されました。
・REPLACE(str, from_str, to_str)
・SUBSTRING_INDEX(str, delim, count)
・TRIM([{BOTH | LEADING | TRAILING} [remstr] FROM] str)
以前は、これらの関数へのすべての引数の文字セット情報が集約されていたため、結果が整数式でない場合がありました。これにより、LPAD()でも問題が発生しました。LPAD()では入力と出力の両方が整形式であると想定されています。現在、上記の3つの関数はそれぞれ、strで使用される文字セットを常に使用し、実行時に他のすべての引数をこの文字セットに変換します。そのような変換が失敗すると、関数はエラーを返します。（Bug #30114420）
参照：この問題はBug #28197977のリグレッションです。
● 重要な変更：サブクエリのマテリアライゼーションでは、内部型と外部型の厳密な一致が不要になりました。次の条件のいずれかに該当する時、さまざまな型をマテリアライズすることができます。
・内側型は数値である（常に外部型を数値にキャストする方法があるため）
・内部型は時間に関する値である（常に外部型を時間に関する値にキャストする方法があるため）
・どちらの型も文字列である
(Bug #13960580)
● NDB Cluster：一部のNDBロギングオプションのパスワードマスキングが不完全でした。(Bug #97335, Bug #30453137)
● InnoDB：起動時の特定の内部データ構造の初期化は、max_connections設定から派生した内部変数に依存します。SET PERSISTを使用した起動後にmax_connections設定が変更された時、InnoDBは内部データ構造のサイズ変更に失敗しました。 (Bug #30628872)
● InnoDB：MySQLをGCC 9.2.0でコンパイルする時、os_file_get_parent_dir警告が発生しました。 (Bug #30499288, Bug #97466)
● InnoDB：ヌル参照を使用してラージオブジェクト（LOB）値にアクセスしようとすると、アサーションエラーが発生しました。この問題の発生を防ぐために、LOB参照がアクセスされる前にヌルかどうかを確認するチェックが追加されました。 (Bug #30499064)
● InnoDB：データディレクトリのアップグレード後にアサーションエラーが発生しました。準備されたXAトランザクションがまだ存在していたため、UNDOテーブルスペースがアップグレードされませんでした。準備されたトランザクションの変更を含むUNDOテーブルスペースは、準備されたすべてのXAトランザクションがコミットまたはロールバックされるまでアクティブのままである必要があります。
準備されたXAトランザクションは、また、再起動後の明示的なUNDOテーブルスペースの切り捨て操作の完了を妨げました。 (Bug #30489497)
● InnoDB：大文字のテーブル名（パーティション化された、または、その他）を使用するLinux上のMySQL 5.7インスタンスをmacOS上のMySQL 8.0にアップグレードしようとすると、アサーションエラーが発生しました。MySQL 8.0でのパーティションファイル形式の変更により、データディレクトリを別のプラットフォームに移行できなくなり、lower_case_table_names設定がアップグレード時に変更されました。これによりアップグレードの失敗を引き起こす可能性があります。これらの状況でのエラー発生の代わりに、現在はエラーが報告されます。 (Bug #30450968, Bug #30450979)
● InnoDB：macOSでは、大文字のテーブル名を持つMySQL 5.7インスタンスをMySQL 8.0にアップグレードしようとした時に障害が発生しました。大文字のテーブル名が小文字に正規化されませんでした。次のエラーが報告されました：Table is not found in InnoDB dictionary and Error in fixing SE data errors。 (Bug #30450944)
● InnoDB：Windowsでは、大文字のパーティションテーブル名を持つMySQL 5.7インスタンスをMySQL 8.0にアップグレードしようとした時に障害が発生しました。
テーブルを開くとヌルポインターが返され、テーブルを閉じるときにセグメンテーションエラーが発生しました。 (Bug #30450918)
● InnoDB：Windowsで、大文字のパーティションテーブル名を持つMySQL 5.7インスタンスをMySQL 8.0にアップグレードしようとした時にmysqld例外が発生しました。 (Bug #30447790)
● InnoDB：Windowsで、大文字の名前で定義された一般的なテーブルスペースを含むMySQL 5.7インスタンスをMySQL 8.0にアップグレードしようとした時に障害が発生しました。次のエラーが報告されました：Error in fixing SE data and Failed to Populate DD。 (Bug #30446798)
● InnoDB：LOB関連コードにローカルミニトランザクション（mtrs）を導入すると、リカバリ中にアサーションエラーが発生しました。 (Bug #30417719)
● InnoDB：大文字のパーティションテーブル名を持つWindows上のMySQL 5.7インスタンスをLinux上のMySQL 8.0にアップグレードしようとした時に障害が発生しました。MySQL 8.0のパーティションファイル形式の変更により、データディレクトリの別のプラットフォームへの移行が妨げられました。障害の代わりに、現在はエラーが報告されます。 (Bug #30411118)
● InnoDB：同じ圧縮LOBデータを繰り返し更新すると、テーブルスペースファイルのサイズが増加しました。 (Bug #30353812)
● InnoDB：temptable_max_ramの制限に達すると、TempTableストレージエンジンは、ディスクベースのストレージにフォールバックする代わりに、メモリ不足エラーを誤って報告しました。 (Bug #30314972, Bug #96893)
● InnoDB：暗号化されたテーブルをインポートしてサーバーを再起動した後、そのテーブルにアクセスしようとすると次のエラーが返されました：ERROR 3185 (HY000): Can't find master key from keyring, please check in the server log if a keyring plugin is loaded and initialized successfully。テーブルスペースキーは、対象のマスターキーで暗号化された後、ディスクに書き込まれませんでした。 (Bug #30313734)
● InnoDB：SQLステートメントを解析し、外部キー関連のDDLチェックを実行する内部InnoDB dict_create_foreign_constraints()関数が削除されました。この機能は、MySQL 8.0のデータディクショナリの導入と、その後の外部キー関連DDLチェックのSQLレイヤーへの再配置により、冗長になりました。
dict_create_foreign_constraints()関数の削除により、次の外部キーの問題も解決されました。
・完全修飾参照テーブル名のドット（“.”）の周りのスペースは、InnoDBパーサーによって許可されていませんでした。
・同じALTER TABLEステートメントでの外部キーの追加とパーティションの削除は許可されていませんでした。InnoDBパーサーは、新しいテーブルバージョンがパーティション化されなくなったことを検出しませんでした。
・外部キー制約は、“AUX”という名前のスキーマ内のテーブルを参照できませんでした。参照されているテーブル名を解析した関数は、AUXなどの特別な名前がエンコードされていることを認識しませんでした。
・外部キー定義の条件付きコメントは無視されました。
さらに、ALTER TABLEステートメントの実行の初期段階で、テーブル上に同じ名前の複数の外部キーを作成する試みを検出するために、チェックがSQLレイヤーに追加されました。 (Bug #30287895, Bug #22364336, Bug #28486106, Bug #28703793, Bug #16904122, Bug #92567, Bug #11754659, Bug #46293)
● InnoDB：比較関数は、空間インデックスの非リーフページをマージしようとした時に、2つのレコードが等しいことを検出しました。その関数はこの予期しない状態を処理できなかったため、長いセマフォ待機と最終的アサーションエラーが発生しました。 (Bug #30287668)
● InnoDB：ラージオブジェクト（LOB）ページの解放に必要とされるローカルで取得されたラッチは、ページが解放される前にその後の呼び出し元が同じページのラッチを取得しようとした場合にデッドロックを引き起こす可能性がありました。同様に、ロールバック関連の操作中に圧縮LOBまたは非圧縮LOBでラッチが取得されると、ラッチ順序の問題が原因でデッドロックが発生する可能性がありました。 (Bug #30258536)
参照：この問題はBug #29846292のリグレッションです。
● InnoDB：圧縮されたLOBページをパージしているパージスレッドと、削除マークされたレコードを使用している更新スレッドとの間の競合状態により、アサーションエラーが発生しました。 (Bug #30197056)
● InnoDB：異なるDATA DIRECTORY句を使用して定義されたソーステーブルとデスティネーションテーブルが原因で失敗したテーブルスペースインポート操作は、説明が不十分なスキーマの不一致エラーを報告しました。さらに、.cfgファイルが存在しない場合、同じ操作でアサーションエラーが発生します。現在は、データディレクトリの不一致が原因でインポート操作が終了する前に、より詳細なエラーメッセージが両方のケースで報告されます。 (Bug #30190199, Bug #30190227, Bug #20644698, Bug #76142)
● InnoDB：バッファプールより大きいLOB値をパージしようとした時、パージ操作が失敗しました。 (Bug #30183982)
● InnoDB：外部に保存されたLOBデータをインラインストレージに移動する更新操作は、古いLOBデータをパージ可能としてマークできませんでした。 (Bug #30178056, Bug #96466)
● InnoDB：インデックスキーパーツのソート順情報は、ALTER TABLE ... IMPORT TABLESPACE操作で使用される.cfgメタデータファイルに保存されませんでした。したがって、インデックスキーパーツのソート順は昇順であると想定されていました。これがデフォルトです。その結果、インポート操作に関係する1つのテーブルがDESCインデックスキーパーツのソート順で定義され、他のテーブルはそうでない場合、レコードは意図しない順序でソートされる可能性がありました。この問題に対処するために、.cfgファイル形式はインデックスキーパーツのソート順情報が含まれるように更新されました。 (Bug #30128418)
● InnoDB：修正レコードが修正ツリー構造を必要とするかどうかを検出するbtr_cur_will_modify_tree()関数で使用される基準が不十分でした。 (Bug #30113362)
● InnoDB：スペースIDを取得するために起動時に発生するテーブルスペースファイルスキャンが原因で、多数のテーブルを持つインスタンスで起動が遅くなりました。マルチスレッドスキャンは、テーブルスペースファイルの数が50,000を超え、3つのテーブルスペースページがスペースIDを取得するために読み取られた場合にのみ、開始されました。起動時間を改善するために、現在は、追加のスレッドがテーブルスペースファイルスキャンに割り当てられ、最初のテーブルスペースページのみがスペースIDを取得するために読み取られます。スペースIDがテーブルスペースの最初のページで見つからない場合は、以前と同様に3ページがスペースIDを特定するために読み取られます。 (Bug #30108154, Bug #96340)
● InnoDB：大文字と小文字を区別しないファイルシステムで、同じテーブルスペースIDに対して複数のファイルが見つかったことを示すエラーで、起動が失敗しました。ファイルパスの比較では、innodb_data_home_dirとdatadirのパスの大文字小文字が異なるため、それらのパスが同じであると認識されませんでした。 (Bug #30040815)
● InnoDB：パーティションテーブルとlower_case_table_names=1の設定を持つLinux上のMySQL 8.0.13インスタンスをMySQL 8.0.14またはMySQL 8.0.15にアップグレードした後、永続的オプティマイザ統計テーブルmysql.innodb_index_statsとmysql.innodb_table_statsにアクセスすると、ストレージエンジンエラーが発生しました。永続的オプティマイザ統計テーブルに重複エントリが含まれていました。 (Bug #30012621)
参照：この問題はBug #26925260のリグレッションです。
● InnoDB：テーブルスペースがすでに存在することを示すエラーでCREATE TABLESPACEが失敗しました。このエラーは、DDLは失敗したが、トランザクションのコミット前にロールバックが無効になったために関連する変更がロールバックされなかった先行のCREATE TABLESPACE操作の失敗が原因でした。現在は、トランザクションが正常にコミットされた後に、ロールバックが無効になります。 (Bug #29959193, Bug #95994)
● InnoDB：インポートされたテーブルスペースに属する変更されたページは追跡されませんでした。 (Bug #29917343)
● InnoDB：大文字と小文字を区別しないファイルシステムでMySQL 5.7からMySQL 8.0にアップグレードする時、アップグレード中の全文検索補助テーブルの名前の変更がテーブルスペース名の競合により失敗しました。 (Bug #29906115)
● InnoDB：バッファープールより大きいLOB値を挿入したINSERT操作のロールバックにより、デッドロックが発生しました。 (Bug #29846292)
● InnoDB：セッション一時テーブルのセカンダリインデックスロックの不要な暗黙的から明示的への変換を禁止することによって、コードのリグレッションに対処しました。 (Bug #29718243)
● InnoDB：削除マークの付いたレコードのパージ中に破損したページにカーソルが置かれた時、テーブルスペースのインポート操作でアサーションが発生しました。破損したページが検出された時にアサートする代わりに、現在はインポート操作が終了し、エラーが報告されます。 (Bug #29454828, Bug #94541)
● InnoDB：削除マークされた行は、部分的なロールバックが完了する前に外部読み取りロックを取得できました。外部読み取りロックにより、部分的なロールバック中に暗黙的なロックから明示的なロックへの変換が妨げられ、アサーションエラーが発生しました。 (Bug #29195848)
● InnoDB：スループットが、負荷が高い状況で、小さいinnodb_io_capacity_max設定と単一のページクリーナースレッド、複数のバッファプールインスタンスにより停止しました。 (Bug #29029294)
● InnoDB：UNDOテーブルスペースの切り捨て操作の進行中にサーバーが終了した後、UNDOテーブルスペースページのdoublewriteページを復元できないという警告メッセージが起動時に出力されました。切り捨てられているUNDOテーブルスペースに関して警告メッセージは出力されなくなりました。 (Bug #28590016)
● InnoDB：読み取り専用モード（innodb_read_only=ON）で、SHOW CREATE TABLE出力に外部キー制約に関する情報が含まれていませんでした。 (Bug #21966795, Bug #78754)
● パーティショニング：MySQL 8.0.16以前のサブパーティションテーブルを持つデータベースをアップグレードし、その後ALTER TABLE ADD COLUMNを実行すると、アサーションまたはエラーが発生します。 (Bug #30360695, Bug #97054)
● パーティショニング：MySQL 5.7から8.0へのパーティション化されたテーブルのアップグレード中、プレフィックスキーがパーティション関数で使用された場合、プレフィックスの長さは無視され、代わりに列の全長が考慮されました。その結果、テーブルは、そのパーティションフィールドの長さが長すぎることが判明したため、不正にアップグレードを拒否される場合がありました。 (Bug #29941988, Bug #95921)
● パーティショニング：ALTER TABLE ... EXCHANGE PARTITIONにより、インデックスが破損する可能性がありました。これは、パーティション化されたテーブルでインデックスが作成される順序がパーティション化されていないテーブルの順序と同じであるとサーバーが想定したためです。これにより、間違ったインデックスデータが交換されました。 (Bug #29706669)
● レプリケーション：メンバーがレプリケーショングループに参加または再参加する時、グループレプリケーションが（参加メンバーが既存のオンラインメンバーから状態転送を受信する）分散リカバリプロセスでエラーを検出した場合、新しいドナーに自動的に切り替わり、状態転送を再試行します。参加メンバーが中断前に再試行する回数は、group_replication_recovery_retry_countシステム変数によって設定されます。パフォーマンススキーマテーブルreplication_applier_status_by_workerには、最後の再試行の原因となったエラーが表示されます。以前、このエラーは、グループメンバーが並列レプリケーションアプライヤスレッド（slave_parallel_workersシステム変数で設定）で設定されている場合にのみ表示されました。グループメンバが単一のアプライヤスレッドで設定されている場合、エラーは、内部のRESET SLAVE操作による再試行の度にクリアされたため、表示されませんでした。これは、単一または複数のアプライヤスレッドがあったかどうかに関係なく、SHOW SLAVE STATUSコマンドの出力にも当てはまりました。RESET SLAVE操作は、現在、分散リカバリの再試行後に実行されなくなりました。そのため、最後の再試行を引き起こしたエラーは常に表示されることが可能です。 (Bug #30517160, Bug #30517172)
● レプリケーション：スレーブの関連テーブルにマスターよりも多くの列がある場合、レプリケーションチャネルの権限チェックが実行された時にアサーションが発生しました。そのチェックは、現在、テーブル定義ではなく、イベントの列数を参照します。 (Bug #30343310)
● レプリケーション：STOP GROUP_REPLICATIONが発行されたため、または、エラーのために、レプリケーショングループメンバーがグループを離れる時、グループレプリケーションは、前のグループメンバーが不要なバイナリログデータをグループに残っているメンバーに送ることができないように、バイナリログダンプスレッドを停止します。 (Bug #30315614)
● レプリケーション：mysql.slave_relay_log_infoテーブルに保持されているレプリケーション接続パラメーターは、現在、RESET SLAVEを発行した後、START SLAVEを発行する前に、サーバーがクラッシュまたは意図的に再起動した場合に保持されます。。このアクションは、レプリケーション権限チェックのPRIVILEGE_CHECKS_USERアカウント設定（MySQL 8.0.18で導入）およびREQUIRE_ROW_FORMAT設定（MySQL 8.0.19で導入）に適用されます。relay_log_info_repository=FILEがサーバーで設定されている場合（デフォルトではなく、推奨されていない）、レプリケーション接続パラメーターはこの状況では保持されないことに注意してください。 (Bug #30311908)
● レプリケーション：レプリケーションチャネルがPRIVILEGE_CHECKS_USERアカウントを指定して保護される時、そのアカウントはACL権限を持つ必要がなく、チャネルにレプリケートされたGRANTステートメントによりレプリケーションアプライヤが停止します。この状況で、その動作は正しいですが、アサーションが発生していました。このアサーションは削除されました。 (Bug #30273684)
● レプリケーション：グループレプリケーションが、クローニング操作によるプロビジョニング、RESET MASTERの実行、または、リレーログからの部分的なトランザクションの削除のいずれかに続いて開始された時、RESET SLAVE ALLが内部的に使用され、サーバーの不要な状態をクリアしました。しかし、MySQL 8.0.18では、これにより、グループレプリケーションチャネルに指定されたPRIVILEGE_CHECKS_USERアカウントが削除されました。現在は、RESET SLAVEが代わりに使用され、そのアカウントは削除されません。 (Bug #30262225)
● レプリケーション：マルチスレッドレプリケーションスレーブの場合、slave_preserve_commit_order=1を設定すると、該当するオブジェクトが存在しない時にIF EXISTS句を含むステートメントの順序が保持されるようになりました。以前は、これらの更新はリレーログでそれらに先行するトランザクションの前にコミットされていた可能性があったため、スレーブのリレーログから実行されたトランザクションのシーケンスにギャップが生じていた可能性がありました。 (Bug #30262096)
● レプリケーション：レプリケーションチャネルの権限チェックが実行された時、sql_require_primary_keyシステム変数のセッション値の設定に必要な権限がチェックされていませんでした。そのチェックは現在実行されます。 (Bug #30254917)
● レプリケーション：障害が発生したレプリケーショングループメンバーがマイノリティグループに再参加しようとし、それが許可されなかった時、メモリリークが発生する可能性がありました。 (Bug #30162547, Bug #96471)
● レプリケーション：グループメンバーはレプリケーショングループに再参加する時、グループから既に受信したトランザクションのgroup_replication_applierチャネルのリレーログをチェックし、それらを適用することによって、分散リカバリプロセスを開始します。それから、参加メンバーは、既存のオンラインメンバーから状態転送を開始します。これは、リモートクローニング操作で開始される場合があります。
以前は、リモートクローニング操作の開始時にgroup_replication_applierチャネルが明示的に停止されなかったため、その時点でアプライヤーがまだ既存のトランザクションを適用している可能性があり、エラーにつながる可能性がありました。group_replication_applierチャネルは、リモートクローニング操作が要求される前に停止され、分散リカバリプロセスがドナーのバイナリログからの状態転送に移行する時に再開されます。 (Bug #30152028)
● レプリケーション：メンバーのXComポートがブロックされている間にSTOP GROUP_REPLICATIONが発行された場合、XComスレッドはハングし、シャットダウンは完了しませんでした。XComは現在この状況で終了します。 (Bug #30139794)
● レプリケーション：グループレプリケーションがシングルプライマリモードで実行しており、新しいプライマリサーバーが選択された場合、この時点でログに記録されたメッセージは、新しく選択されたプライマリサーバーのgtid_executedセットと、レプリケーションアプライヤによって取得されたGTIDのセットを提供します。 (Bug #30049310)
● レプリケーション：relay_log_space_limitシステム変数がスレーブ上のリレーログのサイズを制限するように設定され、コーディネータースレッドがこの制限やログの最後の位置に関連するロックを取得する時、マルチスレッドレプリケーションスレーブで内部デッドロックが発生することがありました。 (Bug #29842426)
● レプリケーション：レプリケーショングループメンバーが予期せず停止し、すぐに再起動した場合（例えば、mysqld_safeで開始されたため）、レプリケーショングループメンバーは、group_replication_start_on_boot=onが設定されている場合、自動的にグループへの再参加を試みます。以前は、メンバーの以前のインカネーションがグループから追放される前に再起動と再参加の試行が行われた場合、メンバーは再参加できませんでした。現在、このシナリオでは、グループレプリケーションは自動的にグループ通信システム（GCS）機能を使用して、メンバーの再参加を10回再試行します。再試行の間隔は5秒です。これはほとんどのケースをカバーし、以前のインカネーションがグループから追放されるのに十分な時間を与え、メンバーを再参加させます。group_replication_member_expel_timeoutシステム変数が設定されメンバーが追放されるまでの待機時間がより長く指定されると、自動再参加の試行が今も成功しない可能性があることに注意してください。 (Bug #29801773)
● レプリケーション：レプリケーションスレーブが、マスターログファイル名とマスターログの位置を指定しないCHANGE MASTER TOステートメントを使用してセットアップされ、それからSTART SLAVEが発行される前にシャットダウンし、それからオプション--relay-log-recoveryセットで再起動した場合、レプリケーションは開始しませんでした。これが発生したのは、受信スレッドがリレーログのリカバリが試行される前に開始されていなかったために、マスターログファイル名とマスターログの位置を提供するログローテーションイベントがリレーログで使用できなかったからです。この状況で、スレーブは現在はリレーログのリカバリをスキップして警告を記録し、その後レプリケーションの開始に進みます。 (Bug #28996606, Bug #93397)
● macOS：macOSでは、-DWITH_SSL=systemでMySQLを設定すると、mysql_config出力に静的SSLライブラリの内部CMake名が誤って含まれました。 (Bug #30541879, Bug #97632)
● macOS：Ninjaを使用したmacOSでのビルドは、シンボリックリンクを複数回作成しようとするとエラーで失敗する場合がありました。 (Bug #30368985)
● Microsoft Windows；JSON：Windowsプラットフォームでは、多値インデックスに使用されているメモリは、それを含むテーブルが削除された後に解放されませんでした。 (Bug #30227756)
● Microsoft Windows：Windowsでは、Strawberry Perlがインストールされている場合、-DWITH_SSL=systemはインストールされたOpenSSLヘッダーを見つけることができませんでした。 (Bug #30359287)
● Microsoft Windows：Windowsでは、システムOpenSSLライブラリへのパス名にスペースが含まれている場合、-DWITH_SSL=systemオプションは機能しませんでした。これは現在対処されています。また、他のプラットフォームと同様に、-DWITH_SSL=yesは-DWITH_SSL=systemのように扱われます。 (Bug #30261942, Bug #96739)
● Microsoft Windows：MSVC 2019は、コンパイルエラーのためにソースファイル名が文字化けしていました。これを修正するために、CMake設定の回避策が実装されました。 (Bug #30255096, Bug #96720)
● JSON：文字列要素を文字列のutf8mb4表現と同じバイトシーケンスを含むバイナリ文字列に置き換えることによってJSON列の値を更新しても、何の影響もありませんでした。
この問題の根本的な原因は、JSON文字列とJSONの不透明な値が決して同等と見なされなかった以前に、MySQL 8.0.17の多値インデックスの実装によって導入されたJSON文字列とJSON不透明値の比較の動作の変更でした。その変更後、バイナリデータが一致した場合、それらは等しいと見なされました。
この変更の分析は、それが必要でないことを示しました。さらに、新しい動作は、JSON値の比較に関する既存のドキュメントと競合していました。この問題は、元の動作に戻すことによって修正されています。 (Bug #30348554)
● JSON：JSON_TABLE()を使用したビューは、JSONパス引数がエンコードされた文字セットを保持しませんでした。これは、実際にビューが定義されたものとは異なる文字セットで評価された場合、間違った結果を生成する可能性があることを意味していました。このような場合にJSON_TABLE()が元の文字セットを保持することを確保することで、これは修正されています。 (Bug #30310265)
● JSON：JSON列に機能インデックスを追加すると、文字列の比較に使用される照合が変更され、列を選択する同じクエリによって返される結果は、インデックスなしで取得した結果とは異なります。 (Bug #29723353)
● JSON：JSON_TABLE()の最初の引数が、ストアドプロシージャの実行中に定数であったが、準備中ではそうでなかった場合、その後にステートメントが再度実行された時に再評価されなかったため、プロシージャの最初の実行後に毎回空の結果が返されました。 (Bug #97097, Bug #30382156)
● JSON：クエリがFORCE INDEXを使用する時などのケースでは、テーブルの読み取りコストはDBL_MAXです。これは出力時に2e308に切り上げられました。これはJSONパーサーには大きすぎるため、SELECT JSON_EXTRACT(trace, '$**.table_scan') FROM INFORMATION_SCHEMA.OPTIMIZER_TRACEのようなクエリを使用してオプティマイザートレースの一部を抽出することができませんでした。現在このようなケースでは、1.5e308より大きい値は切り捨てられ、代わりに1e308として出力されます。 (Bug #96751, Bug #30226767)
● MySQL 5.7からMySQL 8.0にアップグレードした後、CLONE INSTANCE操作が次のエラーで失敗しました：ERROR 3862 (HY000): Clone Donor Error: 1016 : Can't open file: './undo001'。アップグレードプロセスにより、孤立したインメモリUNDOテーブルスペースが残されました。 (Bug #30602218, Bug #97784, Bug #30239255, Bug #96637)
● thread_poolプラグインは、パフォーマンススキーマテーブルの整数列の定義で表示幅を使用していました。これにより、整数列の表示幅は現在非推奨であるため、警告がエラーログに書き込まれました。 (Bug #30597673)
● MySQLオプティマイザのハッシュ結合アルゴリズムは、結合バッファを使用して中間結果を保存します。このバッファがオーバーフローすると、サーバーはspill-to-diskアルゴリズムを使用し、ハッシュ結合オペランドの1つを一時ファイルに書き込み、これを適切に処理します。オペランドの1つがプッシュ結合操作のメンバーであるテーブルである場合、この戦略は、プッシュされた結合の原型の1つが結合評価の現在の行である時は常に、ネストされたループ読み取りを使用するすべての子の結果行のプッシュ結合要件と競合し、場合によっては、誤ったクエリ結果が返される可能性がありました。 (Bug #30573733)
● INFORMATION_SCHEMA.VIEWSテーブルへのアクセスは、正しいユーザーに適切に制限されていませんでした。 (Bug #30542333)
● ハッシュ結合中のルックアップに使用されるハッシュ値を作成する時、サーバーはPAD SPACE属性を尊重しませんでした。つまり、PAD SPACE照合を使用する時、'foo'と'foo 'はマッチしませんでした。これは、可能な限り長い文字列と同じ長さまですべての文字列をパディングすることで修正されます。可能な限り長い文字列は、CHAR(N)またはVARCHAR(N)のデータ型の長さ指定子Nから推定されます。 (Bug #30535541)
● セカンダリエンジンからDECIMAL列を含む大きな結果セットを取得する時、テキストプロトコルを介した転送のための列値の文字列への変換はボトルネックとして機能していました。内部テストに反映されているように、このような変換に関与する関数のパフォーマンスは、場合によっては50%も向上しています。 (Bug #30528427)
● FORMAT_PICO_TIME()関数が複数の行を処理するために呼び出された時、1つの行でNULL引数が見つかると、その後のすべての結果はNULLに設定されました。 (Bug #30525561)
● パフォーマンススキーマイベントの時間が測定される時、events_xxxテーブルで報告されるイベントの継続時間は、タイマーの開始値と終了値が等しいイベントに対して0ではなくNULLになる場合があります。 (Bug #30525560)
● 括弧付きクエリにLIMIT句を追加すると、括弧内のロック句が抑制されました。例えば、次のクエリはテーブルをロックしません。
(SELECT ... FOR UPDATE) LIMIT ...;
括弧で囲まれたクエリの外側にLIMIT句を追加することは、括弧内のLIMIT句が上書きされることを目的としています。しかしながら、外側のLIMITは、括弧内のORDER BYも抑制しました。例えば、次のクエリの場合、ORDER BYは抑制されました。
(SELECT ... ORDER BY ... LIMIT a) LIMIT b;
現在、内部のロックとORDER BY句は、外部のLIMIT句によって抑制されません。 (Bug #30521098, Bug #30521803)
● オプティマイザが早期評価のために定数テーブルの条件を抽出する場合、ストアド関数が関係する条件など、評価するにはコストが高いWHERE条件は含まれません。抽出された条件が定数テーブルのみが関係しているためにtrueと評価された場合、WHERE条件全体が誤って削除されました。現在、そのような場合は、WHERE条件を削除する前に、高コストな条件のチェックが実行されます。 (Bug #30520714)
● マテリアライズされたラテラル派生テーブルがDISTINCTを使用した時、派生テーブルは予想通りに外側の行ごとに再マテリアライズされませんでした。 (Bug #30515233)
● EXPLAIN ANALYZEは、WITH RECURSIVEを使用した共通テーブル式では正しく機能しませんでした。 (Bug #30509580)
● 一部のプラットフォームでは、GNUゴールドローダーはメモリ枯渇を発生させる可能性がありました。現在は、Intel 64ビットプラットフォームでのみデフォルトで使用されます。 (Bug #30504760, Bug #96698)
● 一部のLinuxプラットフォームでは、clock_gettime()の代わりのlibstdc++によるシステムコールの使用が原因で、EXPLAIN ANALYZEで高いオーバーヘッドが発生しました。 (Bug #30483025)
● Solaris 11.4では、LDAP認証プラグインを構築できませんでした。 (Bug #30482553)
● MEMBER OF()演算子を使用したクエリは、常に正しく処理されるわけではありませんでした。 (Bug #30477993)
● Visual StudioでのBoostコンパイルは、その後修正されたVC++ 2013バグのBoost回避策により失敗しました。現在、この回避策は、MySQLを使用したBoostコンパイル用にパッチされています。 (Bug #30474056, Bug #97391)
● セカンダリエンジンから多数の整数を含む大きな結果セットを取得する時、テキストプロトコルを介して送信するための整数の文字列への変換がボトルネックとして機能する可能性がありました。この問題を回避するために、このような変換を実行する内部関数のパフォーマンスが改善されました。 (Bug #30472888)
● DockerパッケージにLDAP認証プラグインがありませんでした。 (Bug #30465247)
● mysys/my_handler_errors.hエラーメッセージのタイプミスを修正しました。 (Bug #30462329, Bug #97361)
● innodb_force_recoveryが有効な時にGTIDテーブルを更新すると、デバッグアサーションエラーが発生しました。 (Bug #30449531, Bug #97312)
● MySQLはProtobuf 3.10に対してコンパイルできませんでした。 (Bug #30428543, Bug #97246)
● システムの起動中にバッファされたログ行が失われる可能性がありました。 (Bug #30422941, Bug #97225)
● mysql.userシステムテーブルの名前が変更された場合、サーバーが終了する可能性がありました。 (Bug #30418070)
● ホスト名なしで指定されたロールを無効にすると、サーバーが終了する可能性がありました。 (Bug #30416389)
● 複数のセッションがAUTO_INCREMENT列を持つテーブルに同時INSERT ... ON DUPLICATE KEY UPDATEステートメントを実行しているが、AUTO_INCREMENT値を指定していない場合、挿入は一意のインデックスの違反により失敗する可能性がありました。 (Bug #30194841, Bug #96578)
● lower_case_table_names=2の場合、SHOW TABLESは大文字の名前を持つテーブルの表示に失敗する可能性がありました。 (Bug #29957361)
● サーバーの起動時にコマンドラインでkeyring_encrypted_file_passwordを設定すると、パスワードの値がシステムユーティリティに表示される可能性がありました。 (Bug #29848634)
● LOCK TABLESステートメントを有効にすると、ロックされたテーブルのメタデータの変更により、パフォーマンススキーマまたはセッション変数に対するSHOWクエリがopening_tables状態でハングする可能性がありました。 (Bug #29836204, Bug #92387)
● A AND (B OR C [OR ...])形式のWHERE条件を使用したSELECTは、不可能な範囲になり、サーバーが予期せずに終了しました。 (Bug #29770705)
● JSON形式の監査ロギングの場合、現在はidフィールドに65535より大きな値が含まれることが可能です。以前は、ログアクティビティが活発な場合、1秒に65536より多くのクエリを実行できました。これは、id値に許可された16ビットを超えています。 (Bug #29661920)
● 接続パケットが不完全な場合、クライアントは認証プラグイン名を適切に初期化できませんでした。 (Bug #29630767)
● 特定の条件下で、read_onlyまたはsuper_read_onlyシステム変数を有効にしても、SUPER権限のないユーザーによって実行される同時DDLステートメントがブロックされませんでした。 (Bug #28438114, Bug #91852)
● 設計上、mysqlpumpは、無効なビューを含むデータベースはダンプせずに、終了します。しかし、無効なビューは存在するがダンプされるデータベースのいずれにも存在しない場合でも失敗します。 (Bug #27096081)
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.19リリースノート（MySQLウェブサイト）：
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-19.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。