主な変更点
■ Account Management関連
● 以前は、ユーザーが自分で定義していないルーチンの定義にアクセスするには、ユーザーは非常に幅広いグローバルSELECT権限が必要でした。新しいSHOW_ROUTINE権限が、ルーチン定義へのアクセスを許可する、より制限されたスコープを持つ権限として、代わりに付与されます。（つまり、管理者は、グローバルSELECTを必要としないユーザーからそれを取り消して、代わりにSHOW_ROUTINEを付与できます。）これにより、アカウントは幅広い権限を必要とせずにストアドルーチンをバックアップすることができます。 SHOW_ROUTINEは以下へのアクセスを提供します。 ・INFORMATION_SCHEMA.ROUTINESテーブルの内容。 ・SHOW CREATE FUNCTIONおよびSHOW CREATE PROCEDUREステートメント。 ・SHOW FUNCTION CODEおよびSHOW PROCEDURE CODEステートメント。 ・SHOW FUNCTION STATUSおよびSHOW PROCEDURE STATUSステートメント。 古いバージョンのMySQLからのアップグレードでは、SHOW_ROUTINEを持つユーザーがまだいない場合、グローバルSELECT権限を持つユーザーにSHOW_ROUTINEが付与されます。
■ コンパイル関連
● Solaris：ClangとGCCは、SolarisでのMySQLのコンパイルに使用できるようになりましたが、どちらも実験的なものであり、今のところプロダクションコードには使用できません。 (Bug #30562248) ● EL7およびEL8では、CMake設定はGCC 8の前にGCC 9を探すように調整されました。libmysqlclientはMySQLディストリビューションに同梱されているため、これらのプラットフォームでlibmysqlclientに対してビルドされたクライアントアプリケーションは影響を受け、再コンパイルが必要になる場合があります。 (Bug #30722756) ● Windowsでは、Visual StudioのCMakeコンパイラバージョンチェックが更新され、Visual Studio 2019が現在サポートされているバージョンであることを示します。（バージョンチェックは、-DFORCE_UNSUPPORTED_COMPILER=1を指定してCMakeを実行することによって回避できます。） (Bug #30688403)
■ 非推奨と削除関連
● JSON：以前は、JSON_TABLE()関数を呼び出す時にON EMPTY句とON ERROR句をどちらの順序でも指定できました。これは、ON EMPTYが指定されている場合に常にON ERROR句の前に配置する必要があると規定しているSQL標準と矛盾しています。このため、ON EMPTYの前にON ERRORを指定することは非推奨になり、そうしようとするとサーバーが警告を発行します。非標準構文のサポートは、MySQLの将来のバージョンで削除される予定です。 ● max_length_for_sort_dataシステム変数は、オプティマイザの変更によって使われなくなったり使い道がなくなるため、非推奨になりました。 参照：Bug #30473261。 ● VALUES()を使用してINSERT ... ON DUPLICATE KEY UPDATEステートメントの新しい行の値にアクセスすることは非推奨となり、将来のMySQLリリースで削除される可能性があります。代わりに、MySQL 8.0.19以降で実装されているように、新しい行とその列のエイリアスを使用する必要があります。 例えば、次のステートメントはVALUES()を使用して新しい行の値にアクセスします。 INSERT INTO t1 (a,b,c) VALUES (1,2,3),(4,5,6) ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b); 今後は、代わりに次のようなステートメントを使用する必要があります。これは、新しい行のエイリアスを使用します。 INSERT INTO t1 (a,b,c) VALUES (1,2,3),(4,5,6) AS new ON DUPLICATE KEY UPDATE c = new.a+new.b; または、次のように、新しい行とその各列の両方にエイリアスを使用することができます。 INSERT INTO t1 (a,b,c) VALUES (1,2,3),(4,5,6) AS new(m,n,p) ON DUPLICATE KEY UPDATE c = m+n;
■ JSON関連
● MySQLに含まれているrapidjsonライブラリは、2020年1月16日のGitHubスナップショットにアップグレードされました。Mac OS Xでスナップショットからビルドする時に発生するコンパイラエラーの修正が追加されました。 (Bug #30898701)
■ ロギング関連
● SIGHUPシグナルをサーバーに送信しても、ステータスレポートがエラーログに書き込まれなくなりました。SIGHUPに応答してサーバーによって実行される他のアクションは、引き続き実行されます。 (Bug #30578923) ● JSON形式のエラーログライターはログメッセージにts（タイムスタンプ）を含めるようになりました。その値は、エポック（'1970-01-01 00:00:00' UTC）以降のミリ秒を示す整数です。
■ オプティマイザ関連
● 現在、ネストされたブロックループが使用される場合はいつでもハッシュ結合が使用されます。つまり、ハッシュ結合は次のタイプのクエリに使用できます。 ・Inner non-equi-joins ・Semijoins ・Antijoins ・Left outer joins ・Right outer joins これはMySQL 8.0.18で行われた作業に基づき、ハッシュ結合は少なくとも1つの等結合条件を持つクエリでのみ使用できるという実装の制限を取り除きます。さらに、内部結合と外部結合（セミ結合とアンチ結合を含む）の両方でBatched Key Access（BKA）を使用できるようになりました。これにより、結合バッファーメモリが段階的に割り当てられるため、個々のクエリは実際に解決に必要としない大量のリソースを使い切る必要がなくなります。 この修正により、以前のバージョンのMySQLで使用されていたエグゼキューターをイテレーターエグゼキューターで置き換えるタスクが完了します。これには、セミ結合に変換されていないINクエリのWHERE 値 IN（SELECT 列 FROM テーブル WHERE 条件）形式のクエリと同じ形式に実体化されたクエリ（これらのクエリは古いエグゼキューターからの内部に依存していた）を管理していた古いインデックスサブクエリエンジンの置き換えが含まれます。 (Bug #30528604, Bug #30473261, Bug #30912972) ● 本リリースでは、いくつかの新しいインデックスレベルのオプティマイザヒントが実装されています。これらのヒントは、FORCE INDEXやIGNORE INDEXなどのSQLキーワードを使用する既存のインデックスヒントとほぼ同じように機能します。これらは、将来のMySQLリリースで廃止される予定（最終的には削除される）の同等のインデックスヒントを置き換えることを目的としています。新しいヒントとそれぞれの簡単な説明を以下に示します。 ・JOIN_INDEX：ref、range、index_mergeなどの使用可能なアクセス方法に指定されたインデックスを使用することをMySQLに強制します。これは、FORCE INDEX FOR JOINインデックスヒントと同等です。 NO_JOIN_INDEX：いかなるアクセス方法に指定されたインデックスもサーバーに無視させます。同等のインデックスヒントはIGNORE INDEX FOR JOINです。 ・GROUP_INDEX：GROUP BY操作のインデックススキャンに指定されたインデックスをサーバーに使用させます。FORCE INDEX FOR GROUP BYと同等です。 NO_GROUP_INDEX：GROUP BY操作のインデックススキャンに指定されたインデックスを無視することをMySQLに強制します。同等のインデックスヒントは、IGNORE INDEX FOR GROUP BYです。 ・ORDER_INDEX：行のソートに指定されたインデックスをMySQLに使用させます。これは、FORCE INDEX FOR ORDER BYと同等です。 NO_ORDER_INDEX：サーバーが行のソートを実行するために指定されたインデックスを使用しないようにします。IGNORE INDEX FOR ORDER BYと同等です。 ・INDEX：JOIN_INDEX、GROUP_INDEX、およびORDER_INDEXの組み合わせとして機能し、一部のスコープや全スコープに指定されたインデックスを使用することをサーバーに強制します。FORCE INDEXと同等です。 NO_INDEX：NO_JOIN_INDEX、NO_GROUP_INDEX、およびNO_ORDER_INDEXの組み合わせとして機能します。つまり、一部のスコープや全スコープに指定されたインデックスを無視することをMySQLに強制します。これは、インデックスヒントのIGNORE INDEXと同等です。 指定された列とインデックスを持つテーブルに対してインデックスヒントを使用する次のクエリについて考えます。 SELECT a,b FROM t1 USE INDEX FOR ORDER BY (i_ab) ORDER BY a; 本リリースで導入されたインデックスレベルのオプティマイザヒントを使用すると、このクエリは次のように書き換えることができます。 SELECT /*+ ORDER_INDEX(t1 i_ab) */ a,b FROM t1 ORDER BY a; 新しいインデックスレベルのオプティマイザヒントは、SELECT、UPDATE、およびDELETEステートメントで使用できます。（これは、SELECTおよびUPDATEでのみ使用できるFORCE INDEXまたはIGNORE INDEXを使用するインデックスヒントとは異なります。）したがって、次のようなステートメントが可能です。 UPDATE /*+ INDEX(t1 i_ab) */ t1 SET d = 1 WHERE a = 1 AND b = 2 AND c = 3; DELETE /*+ INDEX(t1 i_a,i_c) */ FROM t1 WHERE a = 1 AND b = 2 AND c = 3; 次のように、同じコメント内に複数のヒントを指定できます。 DELETE /*+ INDEX(t1 i_a) JOIN_INDEX(t1 i_c) */ FROM t1 WHERE a = 1 AND b = 2 AND c = 3; インデックスレベルのオプティマイザヒントは、他のオプティマイザヒントと同時に使用できます。その場合、インデックスレベルのヒントが最初に適用されます。他のオプティマイザヒントの効果は、インデックスレベルのヒントで許可されている一連のインデックスに限定されます。 次に示すように、ビューの作成時にインデックスレベルのヒントを使用することもできます。 CREATE VIEW v1 AS SELECT /*+ NO_INDEX(t1 i_a,i_b) */ a FROM t1 WHERE b IN (SELECT /*+ NO_INDEX(t1 i_ab,i_b) */ a FROM t1 WHERE a > 3) ORDER BY a; これらのインデックスレベルのオプティマイザヒントがインデックスヒントと同じステートメントで使用される場合、インデックスヒントは無視されます。 新しいインデックスレベルのオプティマイザヒントは、USE INDEXではなくFORCE INDEXと同等です。つまり、インデックスレベルのオプティマイザヒントの1つ以上の使用は、テーブル内の行を検索するために名前付きインデックスの1つを使用する方法がない場合にのみテーブルスキャンが使用されることを意味します。USE INDEXの特定インスタンスを使用するのと同じインデックスまたはインデックスのセットをMySQLに使用させるためには、NO_INDEX、NO_JOIN_INDEX、NO_GROUP_INDEX、NO_ORDER_INDEX、またはこれらの組み合わせを使用できます。
■ パッケージ関連
● システムのcurlライブラリにリンクするのではなくcurlを含むバイナリパッケージが、curl 7.69.0を使用するようにアップグレードされました。 (Bug #30866333) ● RPMパッケージの場合、comp_errユーティリティは-testサブパッケージに移動され、テストコンポーネントとしてマークされました。 (Bug #30716034) ● バンドルされているLZ4ライブラリがバージョン1.9.2にアップグレードされました。これにより、mysqlpumpランタイムエラーを発生させるBug #30369643などの特定の問題が修正されました。 参照：Bug #30369643。 ● バンドルされているlibeditライブラリがバージョン3.1にアップグレードされました。
■ パフォーマンススキーマ関連
● パフォーマンススキーマは、セッションごとではなくグローバルにのみ発生する可能性のあるエラーに関するセッション関連の統計情報を収集しました。これは行われなくなったため、エラーインストルメンテーションのメモリオーバーヘッドが削減されます。さらに、グローバルエラーの行は、スレッド、アカウント、ユーザー、またはホストごとに報告されるエラー概要に含まれなくなりました。 (Bug #30311574)
■ プラガブル認証
● LDAPサーバーは、LDAP検索を別のLDAPサーバーに委任するように設定できます。これは、LDAP参照として知られる機能です。ただし、LDAP参照を有効にすると、検索が特定の条件下でLDAP操作エラーで失敗する可能性があります。参照エラーを回避するためにMySQL Enterprise EditionのLDAP認証プラグインを有効にするためには、新しいシステム変数authentication_ldap_simple_referralおよびauthentication_ldap_sasl_referralが使用できます。これらの変数により、各プラグインは、MySQL認証中にLDAPサーバーが参照を使用すべきかどうかを制御できます。 ● MySQL Enterprise Edition SASL LDAP認証プラグインは、Linux上のMySQLクライアントおよびサーバーの認証方法としてGSSAPI/Kerberosに対応するようになりました。これは、アプリケーションがデフォルトでKerberosが有効になっているMicrosoft Active Directoryを使用してLDAPにアクセスするLinux環境で役立ちます。 この機能は、LinuxのすべてのRPMパッケージおよびDEBパッケージで使用可能ですが、TARアーカイブパッケージでは使用できません。
■ SQL構文関連
● 以前は、SELECTステートメントのINTO句は次の2つの位置のいずれかに出現する可能性がありました。 ・FROMの前: SELECT * INTO OUTFILE 'file_name' FROM table_name; ・最後のロック句の前: SELECT * FROM table_name INTO OUTFILE 'file_name' FOR UPDATE; 現在、INTOは、3つ目の位置出現する可能性があります。SELECTステートメントの最後です。 SELECT * FROM table_name FOR UPDATE INTO OUTFILE 'file_name'; INTOを最後に配置することが推奨される位置です。ロック句の前の位置は非推奨であり、そのサポートは将来のMySQLバージョンで削除される予定です。つまり、FROMの後ではあるがSELECTの最後ではないINTOは警告を生成します。 さらに、INTOに関してUNIONにいくつかの変更が加えられました。INTOを含むUNIONのこれらの異なる形は構文的に正しく、同じ結果を生成します。 ... UNION SELECT * FROM table_name INTO OUTFILE 'file_name'; ... UNION (SELECT * FROM table_name) INTO OUTFILE 'file_name'; ... UNION SELECT * INTO OUTFILE 'file_name' FROM table_name; ... UNION (SELECT * INTO OUTFILE 'file_name' FROM table_name); ただし、後の2つの形は、クエリ式全体（UNION）ではなく、名前付きテーブルから情報を収集するかのようで、混乱します。INTOを含むこれら2つのUNIONの形は非推奨になり、それらのサポートは将来のMySQLバージョンで削除される予定です。したがって： ・クエリ式の最後のクエリブロックで、FROMの前にINTOを使用すると警告が出ます。 ・クエリ式の括弧付きの最後のブロックでINTOを使用すると（FROMとの相対位置に関係なく）、警告が出ます。 この非推奨は、全てのINTO形式（INTO OUTFILE、INTO DUMPFILE、およびINTO var_list）に適用されます。
■ テストスイート関連
● perfschema.idx_compare_replication_applier_statusテストケースが更新され、トランザクションの再試行回数の古い値が保存され、トランザクションの再試行回数の新しい値と比較されるようになりました。 (Bug #30810627, Bug #98389)
■ Xプラグイン関連
● Xプラグインの起動中に、MySQLサーバーインスタンスのクライアント接続がmax_connectionsサーバーシステム変数で指定された制限に達した場合、Xプラグインはサーバー設定を取得するためのセッションを作成できず、そのために起動できませんでした。Xプラグインは、起動中に管理セッションを（mysql_admin_sessionサービスを使用して）作成するようになりました。これは、クライアント接続制限の対象ではありません。 (Bug #30894981) ● Xプロトコル接続がすでに多過ぎるためにXプロトコルセッションを初期化できなかった場合、エラーコード5011 Could not open sessionが返されました。現在、この状況では、より関連性の高いエラーコード1040 Too many connectionsが返されます。 (Bug #30753637) ● JSON参照の検証に関する問題により、検証スキーマでコレクションを作成する時にエラーが発生しました。 (Bug #30733330) ● クライアントへのXプロトコル接続を使用するMySQLサーバーインスタンスのシャットダウン中、Xプラグインの競合状態により、無効なクライアント接続が処理のために受け入れられる可能性がありました。無効なクライアントはシャットダウン中にクライアントタイムアウト検証で無視されたため、これらのクライアントは、mysqlx_wait_timeoutシステム変数で設定されたタイムアウトに達するまでシャットダウンをブロックしました。タイムアウトのデフォルトは8時間です。この問題を回避するために、クライアントタイムアウトの検証に、無効な状態のクライアントが含まれるようになりました。 (Bug #30702685) ● MySQL 8.0サーバーに接続する時、Xプラグインはセッションにmysqlクライアントが使用するものとは異なる照合を設定しました。これにより、照合に依存するクエリで問題が発生する可能性がありました。現在、Xプラグインは、utf8mb4文字セットのデフォルトであるutf8mb4_0900_ai_ci照合を使用するようになりました。 (Bug #30516849) ● Xプロトコル接続のワーカースレッドは、作成時にシステムスレッドとして識別され、SYS_defaultリソースグループに割り当てられました。この識別により、それらはリソース管理の目的でユーザーリソースグループに割り当てられることができませんでした。現在、それらはユーザースレッドとして識別され、USR_defaultリソースグループに割り当てられます。Xプロトコルは、現在、CREATE、ALTER、DROP、SET RESOURCE GROUPステートメントに対応していませんが、これらのステートメントは、クラシックMySQLプロトコル接続を使用してXプロトコル接続スレッドで動作できます。 (Bug #30059288) ● Xプラグインは、初期化が開始するとすぐにMySQLシステム変数にアクセスできるようになりました。そのため、プラグインインストールスレッドは、別のスレッドを開始するのではなく、必要な接続自体をセットアップ可能です。 (Bug #29127302)
■ 追加・変更された機能
● 重要な変更：以前は、順序付け操作のペイロードとしてTINYBLOBまたはBLOBより大きいblobタイプの列を含めると、サーバーは行全体ではなく行IDのみのソートに戻りました。これにより、ソートが完了した後、ディスクから行自体をフェッチするための2番目のパスが発生しました。JSON列およびGEOMETRY列はLONG??BLOBとして内部的に実装されているため、これにより、これらのタイプの列では、ほとんど常にLONGBLOBの最大4GB（またはMEDIUMBLOBの最大16MB）よりも短いにもかかわらず、同じ動作が発生しました。現在、サーバーは、TINYBLOB列およびBLOB列と同じように、これらのタイプの列をパックドアドオンに変換します。これにより、テストでパフォーマンスが大幅に向上しました。これに関するMEDIUMBLOB列とLONGBLOB列の処理は変更されていません。 この機能強化の1つの影響は、ソートバッファのサイズが不十分な場合に、非常に大きな（マルチメガバイト）JSON列またはGEOMETRY列の値を含む行をソートしようとすると、メモリ不足エラーが発生する可能性があることです。これは、sort_buffer_sizeシステム変数の値を増やすことにより、通常の方法で補正できます。 (Bug #30400985, Bug #30804356) ● InnoDB：ロックを待機しているトランザクションに優先順位を付けるContention-Aware Transaction Scheduling（CATS）アルゴリズムが改善されました。トランザクションスケジューリングの重みの計算が完全に別のスレッドで実行されるようになり、計算のパフォーマンスと精度が向上しています。 トランザクションスケジューリングにも使用されていたFirst In First Out（先入れ先出し／FIFO）アルゴリズムが削除されました。FIFOアルゴリズムは、CATSアルゴリズムの向上によって冗長になりました。以前にFIFOアルゴリズムによって実行されていたトランザクションスケジューリングは、現在はCATSアルゴリズムによって実行されます。 TRX_SCHEDULE_WEIGHT列がINFORMATION_SCHEMA.INNODB_TRXテーブルに追加されました。これにより、CATSアルゴリズムによって割り当てられたトランザクションスケジューリングの重みに問い合わせできます。 コードレベルのトランザクションスケジューリングイベントを監視するために、次のINNODB_METRICSカウンターが追加されました。 ・lock_rec_release_attempts レコードロックの解放を試行した回数。 ・lock_rec_grant_attempts レコードロックの許可を試行した回数。 ・lock_schedule_refreshes トランザクションスケジュールの重みを更新するためにwait-for（待機）グラフが分析された回数。 ● InnoDB：doublewriteバッファのストレージ領域がシステムテーブルスペースからdoublewriteファイルに移動されました。二重書き込みバッファストレージ領域をシステムテーブルスペースの外に移動すると、書き込み待ち時間が減少し、スループットが増加し、二重書き込みバッファページの配置に関して柔軟性が提供されます。次のシステム変数は、高度な二重書き込みバッファ設定用に導入されました。 ・innodb_doublewrite_dir 二重書き込みバッファファイルディレクトリを定義します。 ・innodb_doublewrite_files 二重書き込みファイルの数を定義します。 ・innodb_doublewrite_pages バッチ書き込みのスレッドごとの二重書き込みページの最大数を定義します。 ・innodb_doublewrite_batch_size バッチに書き込むための二重書き込みページ数を定義します。 ● KILL QUERYまたはCTRL-Cを使用して、実行中にEXPLAIN ANALYZEを停止できるようになりました。 (Bug #30787515) ● EXPLAIN FORMAT=TREEは、ウィンドウ関数の反転情報を表示するようになりました。 (Bug #30770631) ● EXPLAIN FORMAT=TREE出力が改善され、評価されたウィンドウ関数に関する詳細情報が提供され、定期的な集計に提供されるものと一致するようになりました。 (Bug #30573446, Bug #30582782) ● EXPLAIN ANALYZEはFORMATオプションに対応するようになりました。現在、サポートされている形式はTREEのみです。 (Bug #30315224) ● -DWITH_LTO=1 CMakeオプションを使用した設定がmacOSで機能するようになりました。 (Bug #30125902) ● MySQL 8.0.20以降では、MySQLサーバーインスタンスでバイナリログトランザクション圧縮を有効にできます。バイナリログトランザクション圧縮が有効になっている場合、トランザクションペイロードはzstdアルゴリズムを使用して圧縮され、その後サーバーのバイナリログファイルに単一のイベント（Transaction_payload_event）として書き込まれます。圧縮されたトランザクションペイロードは、レプリケーションストリームでレプリケーションスレーブ、他のグループレプリケーショングループメンバー、またはmysqlbinlogなどのクライアントに送信される間は、圧縮された状態のままです。それらは受信スレッドによって解凍されず、圧縮された状態のままでリレーログに書き込まれます。したがって、バイナリログトランザクション圧縮は、トランザクションの発信者と受信者の両方（およびそれらのバックアップ）のストレージスペースを節約し、トランザクションがサーバーインスタンス間で送信される時のネットワーク帯域幅を節約します。 binlog_transaction_compressionシステム変数を使用して、MySQLサーバーインスタンスでバイナリログトランザクション圧縮を有効にできます。これはデフォルトでオフになっています。また、binlog_transaction_compression_level_zstdシステム変数を使用して、圧縮に使用されるzstdアルゴリズムのレベルを設定することができます。この値は、圧縮のエフォートを決定します。1（最低エフォート）から22（最高エフォート）までです。 ● CHANGE MASTER TOステートメントの新しいオプションであるREQUIRE_TABLE_PRIMARY_KEY_CHECKにより、レプリケーションスレーブはプライマリキーチェック用に独自のポリシーを選択できます。レプリケーションチャネルのオプションがONに設定されている場合、スレーブはレプリケーション操作で常にsql_require_primary_keyシステム変数の値ONを使用し、プライマリーキーを必要とします。オプションがOFFに設定されている場合、スレーブはレプリケーション操作で常にsql_require_primary_keyシステム変数に値OFFを使用するため、マスターでプライマリーキーが必要な場合でも、プライマリーキーは必要ありません。REQUIRE_TABLE_PRIMARY_KEY_CHECKオプションがデフォルトのSTREAMに設定されている場合、スレーブはどんな値が各トランザクションに対してマスターからレプリケートされても使用します。 ・マルチソースレプリケーションの場合、REQUIRE_TABLE_PRIMARY_KEY_CHECKをONまたはOFFに設定すると、スレーブは異なるマスターのレプリケーションチャネル全体で動作を標準化し、sql_require_primary_keyシステム変数の一貫した設定を保持できます。ONを使用すると、複数のマスターが同じ一連のテーブルを更新する時にプライマリーキーが誤って失われるのを防ぐことができます。OFFを使用すると、プライマリーキーを操作できるマスターが、できないマスターと一緒に動作することができます。 ・PRIVILEGE_CHECKS_USERがチャネルにレプリケーション権限チェックを適用するように設定されている場合、REQUIRE_TABLE_PRIMARY_KEY_CHECKをONまたはOFFに設定すると、ユーザーアカウントは制限されたセッション変数を設定するためのセッション管理レベルの権限を必要としません。制限されたセッション変数とは、各トランザクションのマスターの設定に一致するようにsql_require_primary_keyの値を変更するために必要なものです。 ● MySQL 8.0.19以降では、Xプロトコル接続を介して送信されるメッセージに対して圧縮がサポートされています。サーバーとクライアントが使用する圧縮アルゴリズムに同意した場合、接続を圧縮できます。デフォルトで、サーバーはDeflate、LZ4、およびzstdの圧縮アルゴリズムを許可します。または、mysqlx_compression_algorithmsシステム変数を設定して、許可するもののみを含むようにできます。MySQL 8.0.19では、Xプロトコルは各アルゴリズムに対してライブラリのデフォルトの圧縮レベルを使用し、クライアントはこれについて交渉することはできません。 MySQL 8.0.20以降では、クライアントはXプロトコル接続の機能ネゴシエーション中に特定の圧縮レベルを要求できます。Xプロトコルは、アルゴリズムごとに最大圧縮レベルを設定します。これは、サーバー上のリソースを消費しすぎる場合に、サーバーがクライアントから要求された高い圧縮レベルに同意することを防ぎます。最大圧縮レベルは、最初はDeflateの場合は5、LZ4の場合は8、zstdの場合は11に設定されています。これらの設定は、新しいシステム変数であるmysqlx_deflate_max_client_compression_level、mysqlx_lz4_max_client_compression_level、およびmysqlx_zstd_max_client_compression_levelを使用して調整できます。 Xプロトコルの新しいデフォルトの圧縮レベルも、パフォーマンステストを通じて、圧縮時間とネットワーク通過時間の間の適切なトレードオフとして選択されています。これらのデフォルトは、必ずしも各アルゴリズムのライブラリのデフォルトと同じではありません。これらは、クライアントがアルゴリズムの圧縮レベルを要求しない場合に適用されます。 デフォルトの圧縮レベルは、最初はDeflateの3、LZ4の2、zstdの3に設定されています。これらの設定は、新しいシステム変数であるmysqlx_deflate_default_compression_level、mysqlx_lz4_default_compression_level、およびmysqlx_zstd_default_compression_levelを使用して調整できます。
■ 主なバグ修正
● パフォーマンス：空間インデックスを持つテーブルに対する特定のクエリは、MySQL 5.7からMySQL 8.0へのアップグレード後に効率的に実行されませんでした。 (Bug #94655, Bug #29488350) 参照：Bug #89551, Bug #27499984。 ● NDB Cluster：NDBは、ルートテーブルのプライマリーパーティションを所有するノードごとに1つのSPJワーカーを定義します。このテーブルがレプリカからの読み取りを使用した場合、DBTCはすべてのSPJワーカーを同じDBSPJインスタンスに配置し、これにより一部のSPJワーカーの使用が効果的に削除されました。 (Bug #30639165) ● NDB Cluster：NDB 8.0.16以前のndb_mgmクライアントバイナリを使用してSHOWコマンドを実行し、NDB 8.0.17以降を実行している管理ノードにアクセスすると、エラーメッセージ Unknown field：is_single_user が生成されました。 (Bug #30599413) 参照：Bug #16275500。 ● InnoDB：パスを指定せずにUNDOデータファイル名を指定したCREATE UNDO TABLESPACE操作は、innodb_undo_directory変数で指定されたディレクトリから同じ名前の既存のUNDOデータファイルを削除しました。ファイル名の競合チェックが、innodb_undo_directory変数で指定されたディレクトリではなく、データディレクトリで実行されました。 (Bug #30908328, Bug #98628) ● InnoDB：デバッグビルドでは、MySQL 8.0.19で導入されたリグレッションにより、ミューテックスとrw-lockデッドロックのデバッグチェックが遅くなりました。(Bug #30886393) 参照：この問題は、Bug #30628872のリグレッションです。 ● InnoDB：Valgrindテストで、条件付きのジャンプまたは移動が初期化されていない値に依存していることを示すエラーが発生しました。このエラーは、検証ロジックが無効なために、誤検知でした。 (Bug #30837136) ● InnoDB：（ソースファイルsync0debug.cc内の）rw_lock_debug_mutex_enter()にバリアがないと、スレッドが起こされることなく待機する可能性があります。 (Bug #30819167) ● InnoDB：サーバーの初期化速度を向上させるため、REDOログファイルにスペースを割り当てるためにfallocate()が使用されるようになりました。 (Bug #30804431) ● InnoDB：データディクショナリテーブルオープン関数が、誤ったロックの順序付けを備えて実装されました。 (Bug #30782103, Bug #97825) ● InnoDB：MySQL 8.0.17で導入された並列読み取りスレッド機能の変更により、SELECT COUNT(*)のパフォーマンスが低下しました。ページがディスクから不必要に読み取られました。 (Bug #30766089) ● InnoDB：DDLロギングは、init_fileスタートアップ変数を使用してブートストラップスレッドによって実行されたSQL操作に対して実行されませんでした。そのため、DDL後の段階で削除されるはずのファイルが残されていました。 (Bug #30721214) ● InnoDB：特定の数のレコードを持つテーブル上のJSON配列としてキャストされた列へのインデックスの追加が、“Incorrect key file for table”エラーで失敗しました。 (Bug #30709525, Bug #98098) ● InnoDB：Valgrindエラーが、初期化されていないlock-> writer_threadの値が条件付きジャンプで使用されたことを報告しました。 (Bug #30694177) ● InnoDB：内部のバッファプール統計カウンター（n_page_gets）は、複数のスレッドからアクセスされた時の競合を避けるために、ページ番号で分割されました。 (Bug #30604841, Bug #97822) ● InnoDB：.cfgファイルとデータディクショナリの両方にALGORITHM=INSTANTを使用して追加された列のデフォルト値が含まれているために、テーブルスペースのインポート操作がスキーマ不一致エラーで失敗しました。エラーは、デフォルト値が異なる場合にのみ発生します。 (Bug #30561144) ● InnoDB：遅いシャットダウンで一部のGTIDのフラッシュに失敗し、UNDOログからフラッシュされていないGTIDをリカバリする必要がありました。 (Bug #30548229) ● InnoDB：パフォーマンススキーマのメモリ割り当てのためにメモリにプレフィックスを割り当てるコードのアラインメント要件が壊れていると、macOSおよびFreeBSD用に最適化されたMySQLビルドで障害が発生しました。 (Bug #30530857) ● InnoDB：仮想列の追加は、テーブル用に作成された新しいデータディクショナリオブジェクトから欠落していたデータが原因で、アサーションエラーを発生させました。 (Bug #30524263) ● InnoDB：UNDOテーブルスペースのモードをチェックする時、必要なラッチが取得されませんでした。UNDOテーブルスペースが空であるかどうかをチェックする時も、必要なラッチが取得されませんでした。 (Bug #30509134) ● InnoDB：トランザクションがデータ変更を実行する前に、GTID値の永続化のために更新UNDOログセグメントをXAトランザクションに割り当てると、失敗しました。 (Bug #30456328) ● InnoDB：破棄されたテーブルスペースを持つパーティションテーブルで実行されたクエリは、アサーションエラーを発生させました。 (Bug #30437407, Bug #97271) ● InnoDB：クラスタ化インデックスレコードを削除済みとしてマークし、そのレコードの更新バージョンをクラスタ化インデックスに挿入するrow_upd_clust_rec_by_insert関数は、誤ったn_ext値（外部フィールドの総数）を下位レベルの関数に渡し、アサーションエラーを引き起こしました。 (Bug #30437378) ● InnoDB：クローニング操作中、シャットダウン時のデータディクショナリバッファテーブルへの書き込みが遅すぎたために、エラーが発生しました。新しく生成されたダーティページがフラッシュされていませんでした。 (Bug #30427369, Bug #30405535, Bug #30405535) ● InnoDB：非圧縮に設定されたinnodb_buffer_pool_evictデバッグ変数を使用して実行された操作により、アサーションエラーが発生しました。 (Bug #30405531) ● InnoDB：GCCビルトインを使用またはビルトインが使用できない時にはos_mutexを使用してboolean型の再帰フラグとライタースレッドIDへのアクセスの順序付けを制御する読み取り書き込みロックコード（rw_lock_t）が、一部のインスタンスでC++ std::atomicを使用するように改訂されました。 (Bug #30401416, Bug #97150) ● InnoDB：MySQL 5.7からMySQL 8.0へのアップグレード中にエラーが発生しました。サーバーデータディクショナリオブジェクトは、FULLTEXTインデックスを削除した後に残っているFTS_DOC_ID列とFTS_DOC_ID_INDEXに関する情報を見つけられませんでした。 (Bug #30357954) ● InnoDB：並列スキャンに関する不要なメッセージがエラーログに出力されました。 (Bug #30330448) ● InnoDB：MySQL 5.7からMySQL 8.0へのアップグレード中に、GEN_CLUST_INDEXという名前のクラスタ化インデックスの名前がPRIMARYに変更され、クラスタ化インデックスの重複エントリーがmysql.innodb_index_statsテーブルに追加されました。(Bug #30330448) ● InnoDB：さまざまな内部関数が一貫性のない方法で書き込みイベントスロットを計算しました。 (Bug #30228108, Bug #96519) ● InnoDB：特定の状況下では、テーブルスペース暗号化キー情報がクラッシュリカバリのREDOログ適用フェーズ中に適用されない可能性がありました。 (Bug #30209760) ● InnoDB：ファイル操作の失敗がページトラッキングアーカイバの失敗を引き起こし、次にメインスレッドがハングし、その結果、アサーションエラーが発生しました。また、誤って、ページトラッキングアーカイバがinnodb_read_onlyモードで有効のままでした。 (Bug #30202643) ● InnoDB：ALGORITHM=INSTANTを使用して追加されたテーブル列を含むテーブルスペースをインポートしようとすると、インデックス破損エラーが報告されました。エラーは、即座に追加された列に関連付けられたメタデータが欠落していることが原因でした。 (Bug #30191523, Bug #96477) ● InnoDB：LOBレコードをフェッチしようとするトランザクションがnull LOB参照を検出したため、アサーションエラーが発生しました。ただし、null LOB参照は、LOB値がまだ完全に書き込まれていないため、この特定のシナリオでは有効でした。 (Bug #30144303) ● InnoDB：並列読み取り操作中、自動コミットが無効になっている時にテーブルロード操作をロールバックすると、サーバーは並列読み取り中にツリー構造が変更される可能性を考慮していないアサーションコードが原因で終了しました。 (Bug #30060690) ● InnoDB：ロールバックセグメントメモリオブジェクトに保持されている現在のサイズの値が無効であることが判明したため、関数trx_purge_free_segment()でアサーションエラーが発生しました。現在のサイズの値を検証するために、検証ルーチン (trx_rseg_t::validateCurrSize()) が追加されました。 (Bug #29947027) ● InnoDB：無効なパラメーター値を使用して実行された準備済みステートメントはアサーションエラーを発生させました。 (Bug #29880907) ● InnoDB：列の追加操作により、アサーションエラーが発生しました。このエラーは、ダングリングポインタが原因でした。 (Bug #29866408) 参照：この問題は、Bug #28491099のリグレッションです。 ● InnoDB：文字列値を取得する特定のInnoDBシステム変数を更新すると、Valgrindテスト中に無効な読み取りエラーが発生しました。 (Bug #29717909, Bug #95215) ● InnoDB：UNDOテーブルスペースへの変更に関するREDOログレコードは、追加のバイトを必要とするUNDOテーブルスペースID値の変更により、MySQL 8.0でサイズが増加しました。REDOログレコードサイズの変更により、書き込みI/Oが多いワークロードでパフォーマンスが低下しました。この問題に対処するために、REDOログのフォーマットが変更され、UNDOテーブルスペースを変更するためのREDOログのレコードサイズが削減されました。 (Bug #29536710) ● InnoDB：進行状況データを含むInnoDBファイル書き込みに関する追加情報がエラーログに出力されるようになりました。 (Bug #29472295, Bug #94634) ● InnoDB：空間インデックスを持つテーブルに対するinsertステートメントは、タプルの破損が原因でレコードタイプの不一致アサーションを発生させました。 (Bug #29465567) ● InnoDB：UNDOログのレコードサイズを計算する関数は、UNDOログレコードが破損している場合、誤った長さの値を計算し、mallocが失敗する可能性がありました。誤った計算を検出するためにアサーションコードが追加されました。 (Bug #29448406, Bug #82734) ● レプリケーション：グループレプリケーションのメッセージサービスによって使用されるスレッドは、パフォーマンススキーマのインスインストゥルメンテーションによって正しく登録されませんでした。そのため、スレッドアクションはパフォーマンススキーマのテーブルに表示されませんでした。 (Bug #30824676) ● レプリケーション：グループレプリケーションは、分散リカバリのクローン作成操作を開始および管理しますが、クローン作成をサポートするように設定されているグループメンバーもユーザーが手動で開始するクローン作成操作に参加できます。MySQL 8.0.20より前のリリースでは、クローン作成操作にグループレプリケーションが実行中のグループメンバーが参加した場合、クローン作成操作を手動で開始することができませんでした。MySQL 8.0.20以降では、クローン作成操作で受信者のデータが削除および置換されない場合、これを行うことができます。したがって、グループレプリケーションが実行されている場合は、クローン作成操作を開始するステートメントにDATA DIRECTORY句を含める必要があります。 (Bug #30798640) ● レプリケーション：グループレプリケーションチャネルの場合、グループレプリケーションの実行中にPRIVILEGE_CHECKS_USERオプションを使用してCHANGE MASTER TOステートメントを発行すると、チャネルのリレーログファイルが削除されました。受信され、リレーログにキューイングされていたが、まだ適用されていないトランザクションは、この状況では失われる可能性がありました。CHANGE MASTER TOステートメントは、グループレプリケーションが実行されていない時にのみ発行できるようになりました。 (Bug #30655369) ● レプリケーション：グループレプリケーションのエラー検出メカニズムは、サーバーがメッセージの送信を停止した場合に疑いを引き起こし、メンバーはグループメンバーの過半数がまだ通信している場合に最終的に追放されます。ただし、エラー検出メカニズムは、過半数を占めている1つ以上のグループメンバーが実際にすでに追放のマークが付けられているが、まだグループから削除されていないという状況を考慮しませんでした。ネットワークが不安定で、メンバーがさまざまな組み合わせでお互いへの接続を頻繁に失ったり取り戻したりした時、グループがその全てのメンバーに追放のマークを付けてしまう可能性があり、その後、グループは消滅し、再度セットアップする必要がありました。 グループレプリケーションのグループコミュニケーションシステム（GCS）は、追放のマークが付けられたグループメンバーを追跡し、過半数があるかどうかを判断する時に、それらのメンバーを疑わしいメンバーのグループにあるかのように扱います。これにより、少なくとも1つのメンバーがグループに残り、グループが存在し続けることができます。追放されるメンバーが実際にグループから削除された場合、メンバーが可能であればグループに再参加できるように、GCSはメンバーに追放のマークを付けた記録を削除します。 (Bug #30640544) ● レプリケーション：機密情報がプレーンテキストで表示されないように、SQLステートメントがバイナリログ用に書き直されている最中に、SHOW PROCESSLISTステートメントがクエリを検査するために使用されると、そのクエリがバイナリログに書き込まれた時に破損する可能性があり、レプリケーションが停止します。クエリの書き換えプロセスはプライベートに保たれるようになり、クエリスレッドは書き直しが完了した時にのみ更新されます。 (Bug #30569003, Bug #97531, Bug #30654405) ● レプリケーション：GRANTステートメントまたはREVOKEステートメントが部分的にしか実行されない場合、インシデントイベントがバイナリログに記録されます。これは、手動でスレーブをマスターと調整できるように、レプリケーションスレーブのアプライアスレッドを停止させます。以前は、失敗したGRANTステートメントまたはREVOKEステートメントがセッションで実行された最初のステートメントである場合、GTIDがインシデントイベントに全く適用されず（キャッシュマネージャーがまだセッションに存在しないため）、レプリケーションスレーブでエラーが発生しました。また、GRANTステートメントがユーザーを作成したが、その後権限が誤って指定されていたために失敗したという状況では、インシデントイベントはログに記録されず、再びレプリケーションスレーブでエラーが発生しました。これらの問題は両方とも修正されました。 (Bug #30566518, Bug #30324661) ● レプリケーション：サーバーの起動後にthread/sql/compress_gtid_tableスレッドが起動されると、mysql.gtid_executedテーブルの圧縮がトリガーされるようになりました。そして、圧縮プロセスが完了するとその影響が表示されます。 (Bug #30541799) ● レプリケーション：高負荷状態で実行されているグループレプリケーションを使用するMySQLサーバーでパフォーマンススキーマテーブルにアクセスできませんでした。 (Bug #30112711, Bug #30675790) ● レプリケーション：ローカルグループメンバーの統計情報に関するグループレプリケーションからパフォーマンススキーマへの内部クエリは、グループのメンバーシップへの変更と同時に発生した場合、失敗しました。この問題を修正するために、内部クエリのロックが改善されました。 (Bug #30049349, Bug #30791583, Bug #30963553) ● レプリケーション：マスターからレプリケーションスレーブが計画外に切断された場合、マスターのダンプスレッドへの参照が登録済みスレーブのリストから削除されないことがありました。その場合、スレーブのリストにアクセスしたステートメントは失敗しました。この問題は修正されました。 (Bug #29915479) ● レプリケーション：パーティションテーブルが関係していた場合、サーバーは、キャッシュスペースの不足が原因で行イベントをバイナリログに書き込むことができない状況を正しく処理しませんでした。この状況で適切なエラーが返されるようになりました。 (Bug #29848931) ● レプリケーション：グループレプリケーションの分散リカバリプロセス中に、参加しているメンバーがグループからのドナーとのリモートクローニング操作を完了できない場合、ドナーのバイナリログからの状態転送を使用して、全ての必要なデータを取得します。ただし、最後に試行されたリモートクローニング操作が中断され、参加しているメンバーが不完全なデータと共にまたはデータなしで残された場合、直後の状態転送の試行も失敗する可能性がありました。リモートクローニング操作が失敗した後の状態転送を試みる前に、グループレプリケーションは、リモートクローニング操作が、参加しているメンバーからローカルデータを削除する段階に達していないことを確認するようになりました。データが削除された場合、参加しているメンバーはグループを離れ、group_replication_exit_state_actionシステム変数で指定されたアクションを実行します。 (Bug #29669099, Bug #29944828) ● レプリケーション：binlog_format=MIXED、tx_isolation=READ-COMMITTED、およびbinlog_row_image=FULLの設定を使用して、トランザクションストレージエンジンを含むINSERT ... SELECTクエリは、バイナリログに書き込まれる行イメージからnull値の列をすべて削除しました。これは、INSERT ... SELECTステートメントを処理する時に、バイナリログ形式が選択される前に、列が挿入用にマークされたことが原因で、発生しました。この問題は修正されました。 (Bug #29110804, Bug #93423) ● レプリケーション：特定のアクションを実行する前に、グループレプリケーションはサーバーで実行されているトランザクションをチェックします。以前は、このチェックに使用されるサービスがコミットフェーズにあるトランザクションをカウントしなかったため、アクションがタイムアウトになる可能性がありました。現在は、コミットフェーズにあるトランザクションは、現在進行中のトランザクションの集合に含まれています。 (Bug #28327838) ● JSON：JSON_TABLE()がstrictモードのINSERTステートメントの一部として使用された場合、ON ERROR句によって処理された変換エラーにより、INSERTが拒否される可能性がありました。エラーはON ERROR句によって処理されるため、ERROR ON ERRORが実際に指定されていない限り、ステートメントは拒否されません。 この問題は、NULL ON ERRORまたはDEFAULT ... ON ERRORが指定されているか暗黙指定されている場合に、値をターゲットタイプに変換する時に警告を無視することによって修正されます。 (Bug #30628330) ● JSON：JSON_TABLE()からの出力は、ビューで使用された場合、必ずしも正しくありませんでした。この修正により、次の問題が修正されます。 ・列名に引用符が付けられていなかったため、引用符が必要な場合に構文エラーが発生していた。 ・一部のカラムタイプが誤って報告された。 ・UNSIGNEDなどの一部の列タイプ属性が失われた。 ・列の文字セットと照合が失われた。 (Bug #30263373) ● JSON：関数JSON_SCHEMA_VALID()およびJSON_SCHEMA_VALIDATION_REPORT()は、それらの引数を含む準備済みステートメントが実行される度に、その引数がJSONに変換可能であることを確認するために以前チェックされていましたが、それは効率的でもなく必要もありませんでした。現在、このような場合、そのチェックはステートメントが準備される時に一度だけ実行されます。 （バグ＃97878、バグ＃30622327） ● SYSTEM_USER権限のあるDEFINERを持つ保存済みオブジェクトについて、権限要件が誤ってチェックされました。 (Bug #31077699) ● MySQLソースから生成されたドキュメント内のClangによって報告されたいくつかのエラーについて修正が行われました。 (Bug #30956093) ● FreeBSDでは、krb5パッケージが依存パッケージになりました。 (Bug #30887620) ● クエリに同じ共通テーブル式（CTE）への複数の参照とそのCTE定義の境界を越えた疑似コメントが含まれている場合、パーサーは紛らわしい構文エラーメッセージを出して失敗しました。 (Bug #30871301) ● Debianパッケージを使用したインストールの場合、/var/run/mysqldディレクトリが作成されませんでした。 (Bug #30855015, Bug #98484) ● SQLステートメントがエラーを返した時、mysqlslapはそのスレッドを適切にシャットダウンしませんでした。これにより、すでに解放されているメモリを解放しようとする可能性がありました。 (Bug #30850310) ● キーが重複している場合にXプラグインがドキュメントを挿入または更新としてコレクションに追加しようとした時、ドキュメントがプライマリーキー以外のフィールドの一意キー制約に失敗した場合、Xプラグインによって返されたエラーはこれが問題の原因であるとは述べませんでした。適切なエラーが返されるようになりました。 (Bug #30843865) ● リゾルバーの変換によって生成された整数値が、ブール値を期待するテストに提供されました。 (Bug #30837240) ● 大きな文字列値を保持する1つ以上の列にアクセスするIN式を使用したクエリは、メモリリークを引き起こす可能性がありました。 (Bug #30814171) ● DELETEのターゲットが共通テーブル式である場合、ステートメントは適切に機能しませんでした。 (Bug #30796015, Bug #98330) ● create_admin_listener_threadを有効にしてadmin_addressを有効にせずにサーバーを起動すると、サーバーはシャットダウンプロセス中に異常終了されました。 (Bug #30785609) ● テーブルのプライマリーキーとセカンダリーキーの両方が同じ列にあるが、長さが異なる場合、範囲オプティマイザは範囲値を比較するためにセカンダリ―インデックスの誤ったキー部分を選択しました。 (Bug #30783011) ● いくつかのケースで、引数のタイプが正しくない集約関数でDISTINCTが使用された時に発生したエラーが正しく伝達されませんでした。 (Bug #30782687) ● 圧縮を使用したレプリケーションでは、マスターが再起動された場合、スレーブはアサーションを発生させることがありました。 (Bug #30774692) ● デバッグビルドの場合、サーバーはオプティマイザトレースを出力しようとして終了する可能性がありました。 (Bug #30773218, Bug #98258) ● mysql_real_connect_nonblocking() C API関数がブロッキング動作を示しました。 (Bug #30771233) ● LOCK TABLESがアクティブな場合、INFORMATION_SCHEMAクエリの処理中に、サーバーは内部の一時テーブル（ロックは不要）をロックしようとして、アサーションが発生する可能性がありました。 (Bug #30764651, Bug #98221) ● mysqldumpの内部ネットワークタイムアウトは、ビジーなサーバーまたは応答しないサーバーへの接続に対応するために700秒から86400秒に増やされました。 (Bug #30755992, Bug #98203) ● -DWITH_SASL=path/to/custom/installationを使用した設定により、libsaslがdaemon_memcachedプラグインにリンクされてしまいました。 (Bug #30755301) ● ウィンドウ関数のフレームバッファに関連付けられた一時テーブルを削除した後、フレームバッファの一時テーブルパラメーターがクリーンアップされなかったため、コピーフィールドに関連付けられた文字列バッファが適切に解放されませんでした。 (Bug #30752366) ● libmysqlclient.so.18内のシンボルの無制限のエクスポートに関する問題を回避するために、-libs-compat RPMパッケージがシステムzlibでビルドされるようになりました。 (Bug #30722389, Bug #98130) ● サーバーがヒストグラムサンプリングを途中で終了したため、アサーションエラーが発生しました。サンプリング操作の完了を示す不要なブール変数が削除されました。 (Bug #30717778) ● 加わっている条件の1つが常にfalseであるためにWHERE条件を削除する時、マテリアライズされた派生テーブルが適切にクリーンアップされず、メモリリークが発生しました。 (Bug #30712243) ● 同じGEOMETRY値を使用した複数の比較は常に正しく処理されるとは限りませんでした。 (Bug #30697042) 参照：Bug #30306306。 ● IN()サブクエリを含むWHERE句が追加された場合、MIN()およびMAX()は一部のクエリに対して誤った値を返す可能性がありました。 (Bug #30691682, Bug #98047) ● MySQL Enterprise Firewallが起動時に有効にされたが、ホワイトリストとユーザーテーブルが欠落していた場合、サーバーの起動に失敗しました。 (Bug #30690181) ● 準備済みステートメントの場合、クリーンアップされ実体化された一時テーブルがまだ参照されていると、再実行によりサーバーが終了する可能性がありました。 (Bug #30674598) ● エラーメッセージ ER_WARN_DEPRECATED_SQL_CALC_FOUND_ROWSおよびER_WARN_DEPRECATED_FOUND_ROWSは、エラーログに書き込まれることになっているメッセージの範囲に誤って分類されました。これらは、クライアントに送信されることになっているメッセージとして正しく分類されるようになりました。古いエラーは、エラーログメッセージの範囲にOBSOLETE_ER_WARN_DEPRECATED_SQL_CALC_FOUND_ROWSおよびOBSOLETE_ER_WARN_DEPRECATED_FOUND_ROWSとして指定されるようになりました。(Bug #30673043) ● 外部クエリがEXISTSまたはNOT EXISTSを使用するサブクエリ内の一部の結合は、必ずしも正しく処理されるとは限りませんでした。 (Bug #30671329) ● ORDER BY定数を使用したクエリは許可されますが、この種類のORDER BY句は結果に影響を与えるべきではありません。そのようなクエリは必ずしも正しく処理されるとは限りませんでした。 (Bug #30669493) ● wild_case_match()で範囲外チェックが欠落していたため、ポインターが範囲外を読み取っていました。 (Bug #30668886) ● strconvert()関数は、ファイル名とutf8_general_ci文字列との間の変換には安全ではありませんでした。 (Bug #30668847) ● 固定長のキーを使用する一部のファイルソートは、必ずしも正しく処理されるとは限りませんでした。 (Bug #30665034) ● 非常に大きくなる可能性のある2つの文字列の列（特に、PAD SPACE照合を使用するBLOB列）でハッシュ結合を実行する時、MySQLはソートキー全体を行に格納しました。これは、大量のメモリを必要とすることによりパフォーマンスに影響を与えました。現在は、照合用のハッシュのみが保存されるようになり、64ビットハッシュのコリジョンが発生した場合でも、追加された同等性比較により誤った回答が防止されます。 (Bug #30664831) ● 少なくとも2つのテーブルがセミジョインを使用して他の2つ以上のテーブルに結合され、結合オプティマイザがルーズスキャンを使用することを選択した場合、重複排除しているネストされたループイテレータの下に左側のテーブルの両方を配置することが可能で、過度の重複排除につながりました。複数のテーブルにわたるルーズスキャンを個別の内部構造として扱うことによって、これを修正します。 (Bug #30659810) ● constテーブルとゼロ以上の既知のゼロ式のUNIONでは、正確に1行の派生テーブルは、0行と誤って読み取られる可能性がありました。 (Bug #30655712, Bug #97967) ● MySQL 8.0.19のパッチが無効なINFORMATION_SCHEMAおよびデータディクショナリのバージョン番号を設定しました。将来のバージョン情報エラーを防ぐために、アサーションコードが追加されました。 (Bug #30645158, Bug #97948) 参照：この問題は、Bug #29871530のリグレッションです。 ● イテレーターツリーを設定する時、オプティマイザは、本当に真実であることがわかっている条件をフィルターをかけて取り除き、それ以降は無視するようになりました。 (Bug #30644591) ● 状況によっては、一時MERGEテーブルのSHOW COLUMNSがアサーションを発生させるか、サーバーを終了させる可能性がありました。 (Bug #30640463) 参照：この問題は、Bug #28811287、Bug #92834のリグレッションです。 ● イベントスケジューラでメモリリークが発生しました。 (Bug #30628268) ● 非同期のC API関数を使用すると、すでに解放されたメモリが解放される可能性がありました。 (Bug #30596999, Bug #97805) ● (Bug #30594613) ● CHECK制約を含むテーブルでは、特定の単純なクエリは、過度のメモリ割り当てとパフォーマンススキーマ呼び出しのために効率的ではありませんでした。 (Bug #30594613) ● 特定の状況下では、memcachedコマンドにより、初期化されていないメモリバッファが読み取られ、エラーが発生する可能性がありました。 (Bug #30592346) ● INFORMATION_SCHEMA.INNODB_TABLESへの入力中にスキーマとテーブルのメタデータに対してInnoDBがリクエストを発行し、そのスキーマが削除されると、リクエストとスキーマの間で競合状態が発生し、INNODB_TABLESに対するユーザークエリがエラーを報告する可能性がありました。 (Bug #30591967) ● ALTER USERを使用してアカウントのMAX_USER_CONNECTIONSの値をリセットしても、現在のアカウント接続が存在する場合はすべて終了するまで有効になりませんでした。 (Bug #30578217, Bug #97735) ● 変数を間違ったディレクトリに永続化しようとしたために、SET PERSISTが失敗する可能性がありました。 (Bug #30561982) ● 存在しないテーブルへのアクセスのエラー条件に対してエラーハンドラーが定義されているストアドプログラム内では、テーブルが存在しないデータベースで指定されていたために存在しない場合、ハンドラーは呼び出されませんでした。 (Bug #30561920, Bug #97682) ● MySQLで採用されている重複排除の最適化戦略は、すでに参照されている行IDの内部テーブルを使用し、これらのIDを含む列に対して一意のインデックスを使用します。一意のインデックスのキーが大きくなりすぎた場合（非常に大きな行IDで発生する可能性がありました）、サーバーは代わりにハッシュキーによる重複排除に戻り、他の一時テーブルと同様に、ハッシュフィールドのみに個別のインデックス（一意ではない）を使用しました。後者のインデックスが適切に初期化されなかったため、影響を受けるクエリが適切に実行されず、途中で終了する可能性がありました。 (Bug #30556257) ● デバッグビルドの場合、LOCK TABLESの下で、サーバーは実体化された一時テーブルを誤って処理し、アサーションを生成する可能性がありました。 (Bug #30476213, Bug #97404) ● 実体化されたクエリブロックの内部配列 SELECT_LEX_UNIT::m_query_blocks_to_materializeは、実行間でリセットされませんでした。つまり、それは、準備済みステートメントが2回実行された時に有効ではないオブジェクトを指摘し、2回目の実行は失敗しました。 (Bug #30438038) ● 列の照合を変更しても、サーバーが再起動するまで一意のインデックスには影響しませんでした。 (Bug #30386119, Bug #97103) ● ロールを使用する時、ストアドファンクションのEXECUTE権限は、ストアドプロシージャの権限として扱われました。その結果、関数のロール権限としてEXECUTEを使用することはできませんでした。 (Bug #30376231) ● 列の値が非決定的関数への入力として使用されている条件を含む実体化されたサブクエリは、誤った結果を生成しました。 (Bug #30368937) ● InnoDB memcachedプラグインにいくつかの修正が適用されました。修正により、潜在的なデッドロックの問題、接続リストラッチに関連する問題、および使われなくなったフラッシュミューテックスの削除に対処しました。 (Bug #30354225) ● utf8mb4_0900_bin照合を使用した文字列は、別の照合を使用したutf8mb4文字列と比較できませんでした。現在、両方の文字列に対してutf8mb4_0900_binを使用して比較が行われます。 (Bug #30350111) ● 最適化中に、MySQLは全ての引数が等しいと見なされる条件を削除します。例えば、1 <> 1は削除され、falseに置き換えられます。その際、非決定的な引数を含む条件も削除され、RAND() < RAND()などの条件は不可能な条件と見なされました。現在、オプティマイザは非決定的な引数を含む条件を削除しなくなりました。 (Bug #30311271) ● イベントを削除することにより、イベントのスケジューリングが妨げられる可能性がありました。 (Bug #30301356, Bug #96849) ● イベントスケジューラがValgrindビルドの警告を報告しました。 (Bug #30301340) ● クローンプラグインの使用中にサーバーをシャットダウンすると、Valgrindエラーが発生しました。 (Bug #30248419) ● mysqld-auto.cnfファイルが不正な形式である場合、サーバーは起動されませんでした（予想済み）が、エラーは報告されませんでした（予想外）。 (Bug #30169731, Bug #96501) ● UPDATEステートメントは、行が更新されなかった理由によっては、一致した全ての行が更新されなかった場合に、一致した行（見つかった行）の数に一貫性がない可能性がありました。例えば、WITH CHECK OPTION句を使用してビューを通じて更新されたために更新されなかった行は、一致する行としてカウントされませんでしたが、CHECK CONSTRAINTの失敗のために更新されなかった行はカウントされました。一貫性を保つため、WITH CHECK OPTION句に失敗した行が一致する行としてカウントされるようになりました。 (Bug #30158954) ● クローンディレクトリでMySQLサーバーを再起動する時、InnoDBは、以前サーバーによってドロップされた統計テーブルのテーブルスペースファイルが見つからなかったことを示すエラーを報告しました。 (Bug #30093799) ● サーバーは、ORDER BYを使用するサブクエリがクエリの1つに含まれるUNIONを正しく処理しませんでした。 (Bug #29952565) ● INFORMATION_SCHEMAクエリでは、競合状態により、動的統計テーブルの更新時にキーの挿入が複数回試行され、重複キーエラーが発生する可能性がありました。 (Bug #29948755, Bug #95929) ● SHOW CREATE VIEWは、文字列を返す関数で定義されたビューの照合の不正な組み合わせによって失敗する場合がありました。 (Bug #29904087) ● 述語に科学表記法の数値が含まれるWHERE句を含むクエリは、正しく処理されませんでした。 さらに、文字列として指定された特定の整数を挿入しようとすると、文字列から整数への変換が上手くいかなかった時にサーバーが終了しました。 (Bug #29723340, Bug #30441969) ● ドナーMySQLサーバーインスタンスで発生するエラー（ER_CLONE_DONORエラー）を取得して解析するために、そして、受信者のデータが削除されたかどうかを確認するために、内部インターフェイスが追加されました。 (Bug #29682642) ● DEFAULT値の場合、テーブルから列を削除できませんでした。 (Bug #29661106) ● CONNECTION_CONTROLプラグインの場合、パフォーマンススキーマインストゥルメンテーションは、関連するコードが実際に実行されない限り、検出できないキーをパフォーマンススキーマに使用しました。 (Bug #29539976) ● 列cがnull可能な場合、オプティマイザは、条件 c < c、c > c、およびc <> cが常にfalseであり、全ての行に対して評価される必要がない場合を認識するようになりました。（nullが可能ではない列の場合、オプティマイザは常にfalseの条件を既に認識しています。） (Bug #29115386, Bug #93642) ● Index.xmlから文字セットを再初期化すると、解放後使用エラーが発生する可能性がありました。 (Bug #28956360, Bug #93276) ● パフォーマンススキーマのメモリインストゥルメンテーションオーバーヘッドを削減するための以前の変更により、グループレプリケーションのパフォーマンスが低下するという意図しない影響がありました。 (Bug #28719976) 参照：この問題は、Bug #27500610のリグレッションです。 ● sysスキーマのps_setup_reset_to_default()プロシージャは、MySQL 8.0のデフォルトではなく、MySQL 5.7のデフォルトを使用していました。 (Bug #27636611) ● 一部の接続暗号化の暗号が機能しませんでした。 (Bug #27045306) ● 以前は、mysqlpumpはオプションファイルから[mysql_dump]グループおよび[client]グループを読み取りました。現在、mysqlpumpは[mysqlpump]グループを追加で読み取るようになりました。[mysql_dump]グループはまだ受け入れられていますが、推奨されません。 (Bug #24733245, Bug #83144) ● SELECT DISTINCT ... ORDER BY ...形式のクエリの場合、ORDER BYが結合の最初のテーブルにプッシュダウンされた時、結果が必ずしも正しい順序で並べ替えられるとは限りませんでした。 (Bug #98217, Bug #30760534) ● 可変長キーとして使用されるアイテムに対してNULLインジケータが適切に書き込まれなかったため、そのようなアイテムは全てNULLではないと想定され、特定の照合を使用する時に空の文字列と等しいと見なされました。この問題の目に見える影響の1つは、null可能な文字列を使用する式による順序付けが正しく実行されないことがあったことです。列c1にNULLと空の文字列の値の両方が含まれる、そのようなクエリの例を次に示します。 SELECT c1, SUBSTR(c1, 1) AS c2 FROM t ORDER BY c2; (Bug #98035, Bug #30687020) ● GROUP BY句の式がこの列を含むテーブルの作成時に列の名前に使用されたものとは異なる列名を使用した場合、クエリは不正確な結果を返しました。この例は、元のCREATE TABLEステートメントに示されている列名がIDであるにもかかわらず、クエリがGROUP BY idを使用した場合です。 これは、サーバーが式の列名とテーブルの列名を大文字と小文字を区別して比較したために発生しました。この問題は、このような比較が大文字と小文字を区別しない方法で期待どおりに実行されるようにすることで修正されています。 (Bug #97628, Bug #98222, Bug #30541701, Bug #30761372) ● 他の2つのテーブルを結合した派生テーブルに結合されたテーブルを更新するマルチテーブルUPDATEステートメントは、MySQL 5.6で行われたように適切に最適化されず、派生テーブルを作成するサブクエリでSTRAIGHT_JOINが使用されたかのように扱われました。 (Bug #97418, Bug #30488700)
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.20 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-20.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。