主な変更点
■ Account Management関連
● RELOAD権限を付与すると、ユーザーは様々な操作を実行できます。場合によっては、ユーザーがこれらの操作の一部のみを実行できることが望ましい可能性があります。DBAがRELOADの付与を回避し、許可された操作により厳密にユーザー権限を調整できるようにするために、より限定された範囲のこれらの新しい権限が使用可能です。 ・FLUSH_OPTIMIZER_COSTS：FLUSH OPTIMIZER_COSTSステートメントの使用を有効にします。 ・FLUSH_STATUS：FLUSH STATUSステートメントの使用を有効にします。 ・FLUSH_TABLES：FLUSH TABLESステートメントの使用を有効にします。 ・FLUSH_USER_RESOURCES：FLUSH USER_RESOURCESステートメントの使用を有効にします。 新しい権限は、グローバルレベルでのみ適用されます。 mysql_refresh() C API関数は、様々なFLUSHステートメントの操作と同様の操作を実行しますが、この変更による影響は受けません。それは今も、呼び出される操作に関係なく、RELOAD権限を必要とします。
■ C API関連
● 一部のアプリケーションでは、クエリごとにメタデータを定義すると便利な場合があります。例には、クエリを生成したページのURL、または、監査プラグインやクエリ書き換えプラグインなどのプラグインで使用するためにクエリとともに渡される追加の処理情報が含まれます。MySQLは、クエリ文字列に含まれる特別にフォーマットされたコメントなどの回避策を使用せずに、この機能をサポートするようになりました。 ・クライアント側では、mysql_bind_param() C API関数を使用してクエリ属性を定義できます。これらの属性は、実行のためにサーバーに送信される次のSQLステートメントに適用されます。さらに、mysqlクライアントおよびmysqltestクライアントには、クエリ属性の定義を可能にするquery_attributesコマンドがあります。 ・サーバー側では、コンポーネントサービスがクエリ属性へのアクセスを提供します。query_attributesという名前のコンポーネントは、このサービスを使用して、SQLステートメント内で属性値を取得できるようにするmysql_query_attribute_string()ユーザー定義関数（UDF）を実装します。query_attributesコンポーネントはオプションですが、UDFを使用できるようにするにはインストールする必要があります。 （バグ #27855905、バグ #28686334）
■ コンパイル関連
● aarch64(ARM64)でMySQLをコンパイルするためのパッチを提供してくれたTzachiZidenbergに感謝します。（バグ #31815236、バグ #100664）
■ 接続管理関連
● 着信TCPクライアント接続に一致するアカウントの選択は、アカウントの作成順序の影響を受ける可能性があります。マッチングアルゴリズムをより決定論的にするために、アカウントのホスト名部分のマッチングは、ホスト名を使用して指定されたアカウントのマッチングを試みる前に、特定の順序で、ホストIPアドレスを使用して指定されたアカウントをチェックするようになりました。ホスト名のマッチングは変更されません。
■ 非推奨と削除関連
● MySQL 8.0.23以降、ステートメントCHANGE MASTER TOは非推奨になりました。代わりに、エイリアスCHANGE REPLICATION SOURCE TOを使用する必要があります。ステートメントのパラメータには、MASTERという用語をSOURCEという用語に置き換えるエイリアスもあります。例えば、MASTER_HOSTおよびMASTER_PORTは、SOURCE_HOSTおよびSOURCE_PORTとして入力できるようになりました。START REPLICA | SLAVEステートメントのパラメータMASTER_LOG_POSおよびMASTER_LOG_FILEには、現在、エイリアスSOURCE_LOG_POSおよびSOURCE_LOG_FILEがあります。ステートメントは以前と同じように機能しますが、各ステートメントに使用される用語のみが変更されています。古いバージョンが使用されている場合は、非推奨の警告が発行されます。 新しいステータス変数であるCom_change_replication_sourceが、Com_change_masterステータス変数のエイリアスとして追加されました。ステートメントの古いバージョンと新しいバージョンの両方が、ステータス変数の古いバージョンと新しいバージョンの両方を更新します。 サーバーは、全てのCHANGE MASTER TOステートメントをクエリログのCHANGE REPLICATION SOURCE TOステートメントとして書き換えます。START SLAVE、STOP SLAVE、SHOW SLAVE STATUS、SHOW SLAVE HOSTS、RESET SLAVEステートメントについても同じことが行われます。CHANGE MASTER TOステートメントのイベント名は、ステートメント履歴テーブルのstatement/sql/change_replication_sourceに設定されます。（バグ #32145023） ● gen_blacklist()ユーザー定義関数は非推奨になりました。代わりにgen_blocklist()を使用してください。これは、同様の用語置換操作を実行します。 ● システム変数master_info_repositoryおよびrelay_log_info_repositoryの使用は非推奨になり、それらを設定または値を読み取ろうとすると警告メッセージが発行されます。システム変数は、将来のリリースで削除される予定です。これらのシステム変数は、レプリカの接続メタデータリポジトリとアプライヤーメタデータリポジトリをmysqlシステムデータベースのInnoDBテーブルに書き込むか、データディレクトリのファイルに書き込むかを指定するために使用されました。FILE設定は以前のリリースで既に非推奨になっており、MySQL8.0でレプリケーションメタデータリポジトリのデフォルトはテーブルです。 ● ホストキャッシュのフラッシュは、次のいずれかの方法を使用して実行できます。 ・パフォーマンススキーマのhost_cacheテーブルを切り捨てるTRUNCATE TABLEステートメントを実行します。これには、テーブルのDROP権限が必要です。 ・FLUSH HOSTSステートメントを実行します。これにはRELOAD権限が必要です。 ・mysqladmin flush-hostsコマンドを実行します。これにはRELOAD権限が必要です。 これらの方法は実質的に同等ですが、RELOAD権限を付与すると、ホストキャッシュのフラッシュに加えて、他の多くの操作が可能になります。これは、セキュリティの観点からは望ましくありません。host_cacheテーブルにはより制限ざれたスコープがあるため、そのテーブルのDROP権限を付与することが望ましいです。したがって、FLUSH HOSTSステートメントは非推奨になり、将来のMySQLリリースで削除される予定です。代わりに、host_cacheテーブルの切り捨てを行ってください。 mysqladmin flush-hostsは以前はFLUSH HOSTSステートメントを実行しました。現在、これはhost_cacheテーブルの切り捨てを試行し、切り捨て操作が失敗した場合にのみFLUSH HOSTSにフォールバックします。
■ MySQL Enterprise関連
● 管理者は、許可されたステートメント（許可リスト）の一連のルールを指定するプロファイルを登録することにより、MySQL Enterprise Firewall管理を実行します。以前は、プロファイルは個々のアカウントにのみ関連付けることができたため、特定の許可リストを複数のアカウントプロファイルに適用するためには、プロファイルごとにルールセットを複製する必要がありました。管理を容易にし、柔軟性を高めるために、ファイアウォールはグループプロファイル機能を提供するようになりました。 ・名前付きグループプロファイルを作成できます。グループプロファイルには、メンバーとして複数のアカウントを含めることができ、アカウントは複数のグループプロファイルのメンバーになることができます。 ・各グループプロファイルには、独自の許可リストがあります。プロファイル許可リストは全てのメンバーアカウントに適用されるため、複数のアカウントプロファイル間で複製する必要がありません。
■ オプティマイザ関連
● ハッシュ結合に使用されるハッシュテーブルを、順序付けされていないマルチマップから、マルチマップアダプターで実装された順序付けされていないフラットマップに切り替えました。この変更により、次の改善がもたらされます。 ・より高速なハッシュテーブル ・ハッシュテーブルのオーバーヘッドが少ないため、メモリ使用量が少なくなります。配置およびキー／値の長さに使用されるスペースが少なくなります。多くの等しいキーでメモリ使用量が向上します。これにより、ディスクに流出させることが必要になる頻度も減るはずです。 ・join_buffer_sizeの約2/3に効果的に制限されるのではなく、許可された結合バッファサイズにさらに近づき、ハッシュテーブルが大きくなった時に古いメモリを解放できるようにすることで、メモリ制御を向上させます。 （バグ #99933、バグ #31516149）
■ パフォーマンススキーマ関連
● 以前は動的呼び出しに拡張されたパフォーマンススキーママクロは、処理のオーバーヘッドを削減するために、可能な場合は静的呼び出しに拡張されるようになりました。（バグ #32028160） ● タイマーコードのパフォーマンスオーバーヘッドが削減されました。これは、パフォーマンススキーマを使用する同時実行性の高いワークロードに最も役立つはずです。（バグ #31960377、バグ #101018）
■ プラガブル認証
● MySQL Enterprise Edition SASL LDAP認証プラグインは、MySQLクライアントおよびサーバーの認証方法としてSCRAM-SHA-256をサポートするようになりました。SCRAM-SHA-256はSCRAM-SHA-1に似ていますが、より安全です。SCRAM-SHA-256を使用するためには、Cyrus SASL 2.1.27以降を使用して構築されたOpenLDAPサーバーが必要です。
■ セキュリティ関連
● OpenSSLライブラリがバンドルされているプラットフォームの場合、MySQLサーバー用のリンクされたOpenSSLライブラリがバージョン1.1.1iに更新されました。新しいOpenSSLバージョンで修正された問題については、https://www.openssl.org/news/cl111.txtおよびhttps://www.openssl.org/news/vulnerabilities.htmlで説明されています。（バグ #32260610）
■ 空間データ関連
● 新しいST_HausdorffDistance()関数とST_FrechetDistance()関数は、2つのジオメトリ間の離散フレシェ距離と離散ハウスドルフ距離を、そのジオメトリがどれほど類似しているかを反映して、返します。
■ SQL構文関連
● MySQLは非表示の列をサポートするようになり、それらは通常はクエリに対して非表示になっていますが、明示的に参照される場合はアクセス可能です。
■ Xプラグイン関連
● MYSQL41認証方式を使用するXプロトコル接続の場合、サーバーから送信されたナンスが20バイトより短い場合、接続ロジックはそれを正しく処理しませんでした。（バグ #32036194） ● 結果セットを構築していたクエリが強制終了された場合、Xプラグインはこれをサーバーセッションが強制終了されたことを意味すると解釈し、接続を切断しました。クエリのステータスは、サーバーセッションのステータスとは別にチェックされるようになりました。（バグ #31954296） ● Xプロトコルセッションが、別のXプロトコルセッションが解放およびリセットされると同時に、Xプラグインのステータス変数または設定を表示しようとすると、デッドロックが発生する可能性がありました。現在、状況は適切に処理されています。（バグ #31931873） ● サーバーに接続しているXプロトコルクライアントが、関連するXプラグインのタイムアウト設定（読み取り、書き込み、または、待機タイムアウト）より長くアイドル状態（サーバーに送信されない）のままである場合、Xプラグインは接続を閉じます。読み取りタイムアウトの場合、プラグインはエラーコードER_IO_READ_ERRORを含む警告通知をクライアントアプリケーションに返します。 MySQL 8.0.23以降、Xプラグインは、サーバーのシャットダウンが原因で接続がアクティブに閉じられた場合、または、別のクライアントセッションから切断された接続によって、警告通知を送信するようになりました。サーバーがシャットダウンした場合、警告通知は、接続が開いている認証済みの全てのXプロトコルクライアントに、ER_SERVER_SHUTDOWNエラーコードとともに送信されます。接続が切断された場合、SQLの実行中に接続が切断された場合を除き、警告通知はER_SESSION_WAS_KILLEDエラーコードとともに関連するクライアントに送信されます。この場合、致命的なエラーはER_QUERY_INTERRUPTEDエラーコードとともに返されます。 クライアントアプリケーションは、警告通知を使用して、ユーザーに表示したり、切断の理由を分析して、同じサーバーに再接続を試みるか別のサーバーに再接続を試みるかを決定できます。 ● 従来のMySQLプロトコルでは、SQLクエリがメタデータロックまたはスリープ機能を使用している場合、サーバーへの接続が定期的にチェックされ、それがまだ維持されていることを確認します。そうでない場合は、クエリは停止され、リソースを消費し続けないようにすることができます。以前は、Xプロトコルはこれらのチェックを実行せず、接続がまだ維持されていると想定していました。現在は、Xプロトコルのチェックが追加されています。
■ 追加・変更された機能
● InnoDB：次の操作のパフォーマンスが改善されました。 ・大きなバッファプール（32GBより大きい）を持つMySQLインスタンス上の大きなテーブルスペースを完全削除する。 ・適応型ハッシュインデックスから参照されるかなりの数のページを含むテーブルスペースを完全削除する。 ・一時テーブルスペースの切り捨て。 完全削除または切り捨てられたテーブルスペースのページと関連するAHIエントリは、ページが通常の操作中に検出されると、受動的にバッファプールから削除されるようになりました。以前は、テーブルスペースを完全削除または切り捨てると、フルリストスキャンが開始され、バッファプールからページがすぐに削除されました。これは、パフォーマンスに悪影響を及ぼしました。（バグ #31008942、バグ #98869） ● InnoDB：新しいAUTOEXTEND_SIZEオプションは、テーブルスペースがいっぱいになった時にInnoDBがテーブルスペースのサイズを拡張する量を定義し、テーブルスペースのサイズをより大きな増分で拡張できるようにします。スペースをより大きな増分で割り当てると、断片化を回避し、大量のデータの取り込みを容易にします。AUTOEXTEND_SIZEオプションは、CREATE TABLE、ALTER TABLE、CREATE TABLESPACE、ALTER TABLESPACEステートメントでサポートされています。 AUTOEXTEND_SIZEサイズ列がINFORMATION_SCHEMA.INNODB_TABLESPACESテーブルに追加されました。 ● InnoDB：InnoDBは、暗号化されたテーブルスペースに属するダブルライトファイルページの暗号化をサポートするようになりました。ページは、関連付けられたテーブルスペースの暗号化キーを使用して暗号化されます。 ● InnoDB：InnoDBアトミックコードは、C++ std::atomicを使用するように改訂されました。 ● --all-databasesオプションを指定して呼び出された時、mysqldumpは最初にmysqlデータベースをダンプするようになりました。そのため、ダンプファイルがリロードされる時、他のオブジェクトのDEFINER句で指定されたアカウントはすでに作成されています。（バグ #32141046） ● 無効にされたパフォーマンススキーマとLOCK_ORDERツールインストルメンテーションのオーバーヘッドが特定され、排除されました。（バグ #32105698） ● デフォルト値の式を持つBLOB列とTEXT列について、INFORMATION_SCHEMA.COLUMNSテーブルとSHOW COLUMNSステートメントはその式を表示するようになりました。（バグ #31856459） ● binlogチェックサムのCRC計算は、ARMプラットフォームでより高速になりました。（バグ #99118、バグ #31101633、バグ #32163391） ● MySQLサーバーの非同期接続フェイルオーバーメカニズムは、グループメンバーシップへの変更を自動的に監視し、プライマリサーバーとセカンダリサーバーを区別することにより、グループレプリケーショントポロジをサポートするようになりました。グループメンバーをソースリストに追加し、それを管理対象グループの一部として定義すると、非同期接続フェイルオーバーメカニズムがソースリストを更新して、メンバーシップの変更に合わせてそれを維持し、グループメンバーが参加または離脱する時にグループメンバーを自動的に追加および削除します。新しいユーザー定義関数asynchronous_connection_failover_add_managed()およびasynchronous_connection_failover_delete_managed()は、管理対象ソースを追加および削除するために使用されます。 現在接続されているソースがオフラインになるか、グループを離れるか、過半数でなくなった場合、および、現在接続されているソースの加重優先度がグループ内で最高ではない場合も、接続は別のグループメンバーにフェイルオーバーされます。管理対象グループの場合、ソースの重みは、それがプライマリサーバーかセカンダリサーバーかに応じて割り当てられます。したがって、プライマリに高い重みを与え、セカンダリに低い重みを与えるように管理対象グループを設定したとすれば、プライマリが変更されると、新しいプライマリに高い重みが割り当てられ、そのためレプリカはそれへの接続を介して変更されます。この機能は単一の（管理されていない）サーバーにも適用されるため、より高い加重優先度の別のソースサーバーが使用可能な場合、接続はフェイルオーバーされるようになりました。 ● レプリケーションチャネルは、CHANGE REPLICATION SOURCE TOステートメントのASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONSオプションを使用して、GTIDをまだ持っていない複製されたトランザクションに割り当てるように設定できるようになりました。この機能により、GTIDベースのレプリケーションを使用しないソースから使用するレプリカへのレプリケーションが可能になります。マルチソースレプリカの場合、ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONSを使用するチャネルと使用しないチャネルを混在させることができます。GTIDには、レプリカ自体のサーバーUUID、または、様々なソースからのトランザクションを識別するために割り当てるサーバーUUIDを含めることができます。 フェイルオーバーが必要な場合、任意のチャネルでASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONSを使用してセットアップされたレプリカはレプリケーションソースサーバーを置き換えるためにプロモートされることは不可能で、レプリカから取得したバックアップを使用してレプリケーションソースサーバーを復元することはできません。同じ制限が、任意のチャネルでASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONSを使用する他のレプリカの置換または復元に適用されます。ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONSを使用してセットアップされたレプリカからのGTIDセット（gtid_executed）は非標準であり、別のサーバーに転送したり、別のサーバーのgtid_executedセットと比較したりしないでください。 ● マルチスレッドレプリカ（slave_parallel_workersが0より大きい）の場合、slave_preserve_commit_order=1を設定すると、トランザクションはレプリカのリレーログに表示されるのと同じ順序で実行され、レプリカでコミットされます。実行中の各ワーカースレッドは、以前の全てのトランザクションがコミットされるまで待機してからコミットします。デッドロックの可能性が検出されたため、または、トランザクションの実行時間が関連する待機タイムアウトを超えたために、ワーカースレッドがトランザクションの実行に失敗した場合、ワーカースレッドは、slave_transaction_retriesで指定された回数を自動的に再試行してから、エラーで停止します。一時的でないエラーのあるトランザクションは再試行されません。 マルチスレッドレプリカのレプリケーションアプライヤーは、関連するストレージエンジンによって識別されたデータアクセスのデッドロックを常に処理していました。ただし、アクセス制御リスト（ACL）やメタデータロックを含むロック（例えば、FLUSH TABLES WITH READ LOCKステートメント）など、他の種類のロックはレプリケーションアプライヤーによって検出されませんでした。これにより、コミット順序のロックを伴う3アクターのデッドロックが発生する可能性があります。これらは、レプリケーションアプライヤーでは解決できず、レプリケーションが無期限にハングする原因になります。MySQL 8.0.23から、これらの種類のデッドロックが軽減されるように、コミット順序を保持するマルチスレッドレプリカのデッドロック処理が拡張されました。デッドロックはレプリケーションアプライヤーによって具体的に解決されませんが、アプライヤーはデッドロックを認識し、ハングするのではなく、トランザクションの自動再試行を開始します。再試行が終了すると、レプリケーションは制御された方法で停止するため、デッドロックを手動で解決できます。 ● 新しいtemptable_max_mmap変数は、TempTableストレージエンジンがディスク上のInnoDB内部一時テーブルへのデータの保存を開始する前に、メモリマップされた一時ファイルから割り当てることができるメモリの最大量を定義します。0に設定すると、メモリマップされた一時ファイルからのメモリの割り当てが無効になります。
■ 主なバグ修正
● InnoDB：COMPRESSIONオプションを指定したCREATE TABLE操作が許可され、ホールパンチングをサポートしていないシステムで警告が表示されました。現在は、代わりに、操作はエラーで失敗するようになりました。（バグ #32174200） ● InnoDB：データロード操作の進行中に開始されたアップグレードに続くMySQL DBシステムの再起動により、アサーションエラーが発生しました。（バグ #32173596） ● InnoDB：チェックポイント間の同じUNDOテーブルスペースでの切り捨て操作の数に関するエラーメッセージは、64の制限を誤って示しました。MySQL8.0.22では制限が64から50,000に引き上げられました。（バグ #32151601、バグ #101601） ● InnoDB：rw_lock_tおよびbuf_block_tのソースコード構造のサイズが縮小されました。（バグ #32084500） ● InnoDB：InnoDBテーブルで操作したクエリ式からInnoDB以外のストレージエンジンを使用してテーブルを作成した後、InnoDBトランザクションに一貫性がなくなりました。（バグ #32079103） ● InnoDB：既存のギャップロックが削除されたレコードからロックを継承する場合など、状況によっては、INFORMATION_SCHEMA.INNODB_TRXテーブルに表示されるロックの数が実際のレコードロックの数と異なる場合がありました。 （バグ #32068538、バグ #101305） ● InnoDB：Fil_systemシャーディングコードのオフバイワンエラーが修正され、シャードの最大数（MAX_SHARDS）が69に変更されました。（バグ #32052821、バグ #101260） ● InnoDB：TempTableストレージエンジンのメモリアロケータは、メモリの余分なブロックを不必要に割り当てました。（バグ #32018553） ● InnoDB：コミットされていないデータを含むテーブルに対するSELECT COUNT(*)操作は、不要なI/Oが原因でパフォーマンスが低下しました。 （バグ #31997733、バグ #100966） ● InnoDB：ログライターをシャットダウンする際の競合状態により、アサーションエラーが発生しました。（バグ #31997362） ● InnoDB：ページクリーナースレッドが同期フラッシュモードで最適に使用されなかったため、ページフラッシュ操作の速度が低下したり、場合によっては停止したりする可能性がありました。同期フラッシュモードは、InnoDBがREDOログの空き領域を使い果たしそうになると発生し、ページクリーナーコーディネーターに積極的なページフラッシュを開始させます。（バグ #31994031） ● InnoDB：UNDOログの切り捨てが有効になっている時に頻繁に更新が行われると、パージが遅れました。その遅れは、UNDOテーブルスペースが切り捨てのために選択された時にinnodb_purge_rseg_truncate_frequency設定が一時的に128から1に変更されたことが原因でした。設定を変更したコードは削除されました。（バグ #31991688） ● InnoDB：UNDOテーブルスペースの自動切り捨てにより、パフォーマンスの低下が引き起こされました。この問題に対処するために、UNDOテーブルスペースファイルは16MBで初期化され、最低16MB拡張されます。積極的な成長に対処するために、前のファイルの拡張が0.1秒未満前に発生した場合、ファイルの拡張サイズは2倍になります。拡張サイズの倍増は、最大256MBまで複数回発生する可能性があります。以前のファイルの拡張が0.1秒以上前に発生した場合、拡張のサイズは半分に縮小されます。これも、また、最低16MBまで複数回発生する可能性があります。以前は、UNDOテーブルスペースの初期サイズはInnoDBのページサイズに依存し、UNDOテーブルスペースは一度に4つのエクステントに拡張されました。 UNDOテーブルスペースにAUTOEXTEND_SIZEオプションが定義されている場合、UNDOテーブルスペースは、AUTOEXTEND_SIZE設定と上記のロジックによって決定された拡張サイズの大きい方によって拡張されます。 UNDOテーブルスペースが切り捨てられると、通常は16MBのサイズで再作成されますが、現在のファイルの拡張サイズが16MBを超え、前のファイルの拡張が最後の1秒以内に発生した場合、新しいUNDOテーブルスペースはinnodb_max_undo_log_size変数によって定義されたサイズの4分の1で作成されます。 古いUNDOテーブルスペースページは、次のチェックポイントで削除されなくなりました。代わりに、そのページはInnoDBマスタースレッドによってバックグラウンドで削除されます。（バグ #31965404、バグ #32020900、バグ #101194） ● InnoDB：一時テーブルスペースのスペースの事前割り当て中にposix_fallocate()が失敗すると、エラーが発生し、初期化エラーが発生しました。現在は、代わりに警告が発行されるようになり、InnoDBはスペースを事前に割り当てるためにnon-posix_fallocate()メソッドにフォールバックします。（バグ #31965379） ● InnoDB：無効なポインターにより、DISABLE_PSI_MEMORYソース設定オプションを有効にしてコンパイルされたMySQLサーバーでシャットダウンエラーが発生しました。（バグ #31963333） ● InnoDB：特定のインデックスの新しい統計を計算する内部関数によって保持されている長いSXロックが失敗を引き起こしました。（バグ #31889883） ● InnoDB：INFORMATION_SCHEMA.INNODB_TABLESPACESテーブルは、一部のテーブルとスキーマについてFILE_SIZEが0であると報告しました。関連するテーブルスペースがメモリキャッシュにない場合、そのテーブルスペース名はテーブルスペースファイル名の決定に使用されましたが、これは必ずしも信頼できる方法ではありませんでした。現在は、代わりにテーブルスペースIDが使用されます。テーブルスペース名の使用は、フォールバックメソッドとして残っています。（バグ #31841617） ● InnoDB：FULLTEXTインデックスを完全削除し、テーブルの名前を変更してそれを新しいスキーマに移動すると、FULLTEXT補助テーブルは、適切に名前を変更されず、古いスキーマディレクトリに残りました。（バグ #31773368、バグ #100570） ● InnoDB：MySQL 8.0へのアップグレード後、以前に全文検索インデックスで定義されたテーブルに対してDML操作を実行しようとすると、エラーが発生しました。（バグ #31749490） ● InnoDB：ページ圧縮されたテーブルを使用してテーブルスペースをインポートすると、異なるCOMPRESSION設定で定義されたソーステーブルとインポート先テーブルのスキーマ不一致エラーが報告されませんでした。エクスポートされたテーブルのCOMPRESSION設定は、FLUSH TABLES ... FOR EXPORT操作中に.cfgメタデータファイルに保存されるようになりました。その情報はインポート時にチェックされ、両方のテーブルが同じCOMPRESSION設定で定義されていることが確認されます。（バグ #31744694） ● InnoDB：MySQL Keyringプラグインが機能しているかどうかを確認するために使用されるダミーキーが非アクティブ状態で残され、非アクティブなダミーキーの数が時間の経過とともに増加しました。現在は、実際のマスターキーが存在する場合、代わりにそれが使用されるようになりました。使用可能なマスターキーがない場合は、ダミーのマスターキーが生成されます。（バグ #31737924） ● InnoDB：InnoDBシステムテーブルスペースをデータディレクトリの外に移動した後にINFORMATION_SCHEMA.FILESテーブルにクエリを行うと、innodb_systemファイル名が不明であることを示す警告が発生しました。（バグ #31603047） ● InnoDB：バイナリロギングまたはlog_slave_updatesが無効になっているレプリカを含むレプリケーションシナリオでは、mysql.gtid_executedテーブルのギャップの数が多すぎるため、サーバーが起動できませんでした。ギャップは、InnoDBトランザクションと非InnoDBトランザクションの両方を含むワークロードで発生しました。InnoDBトランザクションのGTIDは、定期的に実行されるGTIDパーシスタースレッドによってmysql.gtid_executedテーブルにフラッシュされますが、非InnoDBトランザクションのGTIDは、レプリカサーバースレッドによってmysql.gtid_executedテーブルに直接書き込まれます。GTIDパーシスタースレッドは、エントリのマージとmysql.gtid_executedテーブルの圧縮を繰り返したために遅れました。その結果、InnoDBトランザクションのGTIDフラッシュリストのサイズは、mysql.gtid_executedテーブルのギャップの数に合わせて時間の経過とともに大きくなり、最終的にサーバー障害とその後の起動障害を引き起こしました。この問題に対処するために、GTIDパーシスタースレッドはInnoDBトランザクションと非InnoDBトランザクションの両方のGTIDを書き込むようになり、GTIDパーシスタースレッドが遅れると、フォアグラウンドコミットは強制的に待機されます。また、gtid_executed_compression_periodのデフォルト設定が1000から0に変更され、デフォルトでmysql.gtid_executedテーブルの明示的な圧縮が無効になりました。 （バグ #31599938、バグ #100118） ● InnoDB：XAトランザクションのGTID値を永続化すると、XAトランザクションのパフォーマンスに影響しました。XAトランザクション用に2つのGTID値が生成され、1つは準備段階用で、もう1つはコミット段階用です。最初のGTID値はUNDOログに書き込まれ、後で2番目のGTID値によって上書きされます。2番目のGTID値の書き込みは、最初のGTID値をgtid_executedテーブルにフラッシュした後にのみ発生する可能性がありました。現在は、両方のXAトランザクションのGTID値のためにUNDOログにスペースが予約されるようになりました。（バグ #31467953、バグ #99638） ● InnoDB：Doxygenソースコードドキュメントの作成時に生成される警告に対処するために、InnoDBソースファイルが更新されました。（バグ #31354760） ● InnoDB：全文検索同期スレッドが、以前に解放された単語をインデックスキャッシュから読み取ろうとしました。（バグ #31310404） ● InnoDB：特定の複製されたXAトランザクションのクリーンアップは、トランザクションオブジェクト（trx_t）の再アタッチに失敗し、アサーションエラーが発生しました。（バグ #31006095） ● InnoDB：サーバー障害に続くALTER TABLESPACE ENCRYPTION操作の再開中に障害が発生したため、テーブルスペース暗号化タイプの設定が適切に更新されませんでした。（バグ #30883833、バグ #98537） ● InnoDB：中断されたテーブルスペース暗号化操作は、サーバーの再起動後に操作が処理を再開した時に、データディクショナリのencrypt_typeテーブルオプション情報を更新しませんでした。（バグ #30883833、バグ #98537、バグ #30888919、バグ #98564） ● InnoDB：スレッドのスリープ遅延とInnoDBに出入りするスレッドに関連する内部カウンター変数が、C++ std::atomicを使用するように改訂されました。組み込みのアトミック操作は削除されました。（バグ #30567060、バグ #97704） ● InnoDB：ディクショナリメモリ変数のフェッチ追加（dict_temp_file_num.fetch_add）およびストア（dict_temp_file_num.store）操作のメモリ順序が緩和されました。 （バグ #30567054、バグ #97703） ● InnoDB：サーバーの起動後にテーブルスペースの暗号化操作を再開したバックグラウンドスレッドが、テーブルスペースのメタデータロックを取得できませんでした。これは、同時DDL操作を可能にし、起動スレッドとの競合状態を発生させました。現在、起動スレッドは、テーブルスペースのメタデータロックが取得されるまで待機するようになりました。（バグ #28531637） ● InnoDB：numa_all_nodes_ptrの呼び出しは、numa_get_mems_allowed()関数に置き換えられました。（バグ #24693086、バグ #83044） ● パーティショニング：ALTER TABLE t1 EXCHANGE PARTITION ... WITH TABLE t2は、t1がパーティション化されたテーブルではない時にアサートを引き起こしました。（バグ #100971、バグ #31941543） 参照：この問題は、バグ #29706669のリグレッションです。 ● レプリケーション：ユーザー定義関数asynchronous_connection_failover_add_source()およびasynchronous_connection_failover_delete_source()のnetwork_namespaceパラメーターは、MySQL8.0.23以降は使用されなくなりました。これらのユーザー定義関数は、非同期接続フェイルオーバーメカニズムのレプリケーションチャネルのソースリストにレプリケーションソースサーバーを追加および削除します。レプリケーションチャネルのネットワーク名前空間は、CHANGE REPLICATION SOURCEステートメントを使用して管理され、グループレプリケーションソースサーバーに特別な要件を持ちます。そのため、ユーザー定義関数で指定しないでください。（バグ #32078189） ● レプリケーション：システム変数transaction_write_set_extraction=XXHASH64が設定されている場合（これはMySQL 8.0のデフォルトであり、グループレプリケーションの要件です）、トランザクションの書き込みのコレクションは、以前はサイズの上限がありませんでした。現在、標準のソースからレプリカへのレプリケーションでは、binlog_transaction_dependency_history_sizeで指定された書き込みセットの数値制限が適用されます。その後、書き込みセット情報は破棄されますが、トランザクションは引き続き実行されます。書き込みセット情報は依存関係の計算に使用できないため、トランザクションは非並行としてマークされ、レプリカで順次処理されます。グループレプリケーションの場合、トランザクションから書き込みを抽出するプロセスは、全てのグループメンバーの競合検出と認証に必要であるため、トランザクションが完了する場合に書き込みセット情報を破棄することはできません。数値制限の代わりに、group_replication_transaction_size_limitで設定されたバイト制限が適用され、その制限を超えるとトランザクションの実行に失敗します。（バグ #32019842） ● レプリケーション：mysqlbinlogの--print-table-metadataオプションが使用された場合、mysqlbinlogは、バイナリログへの書き込み時にサーバーが使用する方法とは異なる方法を数値フィールドの評価に使用したため、これらのフィールドに関連するメタデータ出力が正しくありませんでした。mysqlbinlogはサーバーと同じメソッドを使用するようになりました。（バグ #31956206） ● レプリケーション：レプリケーションチャネルでネットワーク名前空間を使用していて、レプリカからマスターへの最初の接続が中断された場合、その後の接続試行で正しい名前空間情報を使用できませんでした。（バグ #31954087） ● レプリケーション：バックアップが進行中などの理由で、グループレプリケーションアプライヤーチャネル（group_replication_applier）がテーブルのロックを維持しており、そのメンバーがグループから追放され、自動的に再参加しようとした場合、自動再参加の試みは失敗し、再試行しませんでした。現在、グループレプリケーションは、起動と再参加の試行中に、group_replication_applierチャネルが既に実行されているかどうかを確認します。それが起動時の場合、エラーメッセージが返されます。それが自動再参加の試行中の場合、その試行は失敗しますが、group_replication_autorejoin_triesシステム変数で指定されているとおりに追加の試行は行われます。（バグ #31648211） ● レプリケーション：インスタンス上の一部のテーブルがロックされた時点（バックアップの実行中など）で、グループメンバーが追放され、自動再参加が試行された場合、その試行は失敗し、それ以上の試行は行われませんでした。このシナリオは正しく処理されるようになりました。（バグ #31460690） ● レプリケーション：準同期ソースサーバーから複製するレプリカの数が増えると、ロックの競合により、パフォーマンスが低下する可能性がありました。プラグインで使用されるロックメカニズムは、可能であれば共有ロックを使用し、不要なロックの取得を回避し、コールバックを制限するように変更されました。新しい動作は、次のシステム変数を有効にすることで実装できます。 ・replication_sender_observe_commit_only=1は、コールバックを制限します。 ・replication_optimize_for_static_plugin_config=1は、共有ロックを追加し、不要なロックの取得を回避します。プラグインをアンインストールしたい場合は、このシステム変数を無効にする必要があります。 両方のシステム変数は、準同期レプリケーションプラグインのインストールの前か後に有効にでき、レプリケーションの実行中に有効にできます。準同期レプリケーションソースサーバーは、レプリカと同じロックメカニズムを使用するため、これらのシステム変数を有効にすることでパフォーマンス上の利点も得ることができます。（バグ #30519928） ● レプリケーション：コミット順序が保持されているマルチスレッドレプリカでは、ワーカースレッドは、独自のトランザクションをコミットする前に、リレーログで以前に発生した全てのトランザクションがコミットされるのを待つ必要があります。コミット順序の後半でのトランザクションのコミットを待機しているスレッドが、コミット順序の前半でトランザクションに必要な行をロックしたために、デッドロックが発生した場合、デッドロック検出アルゴリズムは待機中のスレッドにトランザクションをロールバックするように通知します。以前は、トランザクションの再試行が利用できなかった場合、トランザクションをロールバックしたワーカースレッドは、コミット順序で他のワーカースレッドに通知せずにすぐに終了し、レプリケーションが停止する可能性がありました。現在、この状況のワーカースレッドは、ロールバック関数を呼び出す順番を待機します。これは、他のスレッドに正しく通知することを意味します。（バグ #26883680、バグ #87796） ● レプリケーション：GTIDは、符号付き64ビット整数の負でない値の数（2の63乗引く1）までのサーバーインスタンスでのみ使用できます。 gtid_purgedの値をこの制限に近い数に設定すると、後続のコミットによってサーバーのGTIDが不足し、binlog_error_actionで指定されたアクションが実行される可能性があります。MySQL 8.0.23以降、サーバーインスタンスがその制限に近づくと、警告メッセージが発行されます。（バグ #26035544） ● Microsoft Windows：Windowsでは、MySQLサーバーをサービスとして実行すると、共有メモリ接続が失敗しました。（バグ #32009251） ● JSON：JSON_ARRAYAGG()は、常に適切なエラー処理を実行するとは限りませんでした。（バグ #31856260、バグ #32012559、バグ #32181438） ● JSON：JSON_SET()、JSON_REPLACE()、または、JSON_REMOVE()を使用してJSON値を更新する場合、ターゲット列はインプレースで更新される可能性があります。これは、更新操作のターゲットテーブルがベーステーブルである場合にのみ発生しましたが、ターゲットテーブルが更新可能なビューである場合、更新は完全なJSON値を書き込むことによって常に実行されました。 現在は、このようなケースでは、ターゲットテーブルが更新可能なビューである場合、インプレース更新（つまり、部分更新）も実行されます。（バグ #25840784） ● JSON：MySQL 8.0.22で行われた作業により、プリペアドステートメントが1回だけ準備されるようになり、JSON関数に対する動的パラメータの処理にリグレッションが導入されました。全てのJSON引数はデータ型MYSQL_TYPE_JSONとして分類され、これは、JSON関数が2種類のJSONパラメータ（JSON値とJSONドキュメント）を受け取ることと、この区別はデータ型だけではできないという事実を見落としていました。バグ #31667405については、JSON引数をスカラー値としてタグ付けできるようにし、一方で他のJSON関数への引数をJSONドキュメントとして処理することで、比較演算子とIN()演算子に関するこの問題は解決されました。 現在の修正では、以下に示すように、特定の引数をJSON値として処理する多くのJSON関数が復元されます。 MEMBER OF()への最初の引数 関数JSON_INSERT()、JSON_REPLACE()、JSON_SET()、JSON_ARRAY_APPEND()、JSON_ARRAY_INSERT()の3番目、5番目、7番目とそれ以降の奇数の引数。（バグ #101284、バグ #32063203） 参照：バグ #31667405。 ● JSON：mysqldを--debugで実行した時、複数値インデックスを使用するクエリを実行しようとすると、エラーが発生しました。（バグ #99833、バグ #31474182） ● thread_poolプラグインを使用すると、アドレスサニタイザーの警告が発生する可能性があります。（バグ #32213294） ● 条件をマテリアライズされた派生テーブルにプッシュダウンし、条件が部分的にプッシュダウンされている間に、オプティマイザは、クエリ変換がWHERE条件に新しい条件を追加した場合、外側のクエリブロックに残る条件の内部fix_fields()関数を呼び出すことがあります。この関数呼び出しからの正常な戻りはエラーとして誤って解釈され、元のステートメントのサイレント障害につながりました。（バグ #32150145） ● ORDER BY句を含むALTER TABLEステートメントを含むストアドプロシージャを複数回呼び出すと、サーバーが終了する可能性がありました。（バグ #32147402） ● ストアドプログラムを含むプリペアドステートメントは、ヒープメモリの解放後使用のメモリ問題を引き起こす可能性がありました。（バグ #32131022、バグ #32045681、バグ #32051928） ● マテリアライズされた派生テーブルを含むINFORMATION_SCHEMAテーブルへのクエリは失敗する可能性がありました。（バグ #32127562、バグ #101504） ● 潜在的なバッファオーバーフローが修正されました。（バグ #32113015、バグ #101448） ● FLOAT値をタイプINTの値に変換すると、Undefined Behavior Sanitizer警告が生成される可能性がありました。（バグ #32099994、バグ #32100033） ● 複数行のクエリでは、LOAD_FILE()関数は全ての行で同じ値に評価されました。（バグ #32096341、バグ #101401） ● 一般的なLinuxのtarファイルディストリビューションでは、解凍後にファイルのアクセス許可が制限されすぎたため、修正するには手動のchmodが必要でした。（バグ #32080900） ● デバッグビルドの場合、ストアドプロシージャにサブクエリを含むプリペアドSETステートメントは、アサーションを発生させる可能性がありました。（バグ #32078387） 参照：バグ #32100210。 ● プリペアドステートメントで、合法的な照合の組み合わせに対して、不正な照合の組み合わせエラーが発生する可能性がありました。（バグ #32077842、バグ #101346、バグ #32145078、バグ #101575） ● 関数REGEXP_LIKE()、REGEXP_INSTR()、REGEXP_REPLACE()は、不正な形式の正規表現パターンに対してエラーを発生させますが、そのような場合にNULLを返して、後続のデバッグアサートを引き起こす可能性もありました。現在は、特定の場合を除いて、これらの関数がNULLを返さないようにします。 関数REGEXP_SUBSTR()は常にNULLを返すことができるため、そのような確認は必要ありません。この関数に関しては、確認が実行されないようにします。（バグ #32053093） ● WITH ROLLUPを使用したHAVING条件でIS NULLまたはIS NOT NULLの集計関数をテストすると、誤った結果が発生しました。（バグ #32049313） ● 内部クエリブロックが現在のクエリブロックでの評価を必要とする集計関数を持つために新しい集計関数が現在のクエリブロックに追加された場合、サーバーは必要に応じてそれにロールアップラッパーを追加しませんでした。（バグ #32034914） ● デバッグビルドの場合、CHECK制約のある特定のCREATE TABLEステートメントでアサーションが発生する可能性がありました。（バグ #32018406、バグ #101180） ● セカンダリエンジンのロード操作中に、不正なBLOBフィールド値がInnoDBから渡されました。（バグ #32014483） ● LOCK_ORDERツールは、InnoDB共有排他ロックを正しく示しませんでした。（バグ #31994052） ● サーバーは、ハッシュ結合の一部として無効な列タイプを使用した集計関数を使用しようとした時に発生したエラーを適切に処理しませんでした。（バグ #31989333） ● INFORMATION_SCHEMA.KEYWORDSテーブルのWORD列の長さは、テーブルの内容によって変わる可能性がありました。（バグ #31982157） ● パフォーマンススキーマのhost_cacheテーブルは、パフォーマンススキーマが無効になっている場合、空であり、ホストキャッシュの内容は公開されませんでした。パフォーマンススキーマが有効になっているかどうかに関係なく、テーブルにキャッシュの内容が表示されるようになりました。（バグ #31978763） ● 前のステートメントが使用後にTHD::mark_used_columnsの元の値を復元しなかった時、HANDLER READステートメントがアサートにヒットすることがありました。（バグ #31977414） ● 圧縮されたテーブルをインポートすると、圧縮されていない時に非常に大きい値がテーブルに含まれている場合、予期しないサーバー終了が発生する可能性がありました。（バグ #31943021） ● ハッシュ結合とLIMITを使用したサブクエリが繰り返し実行された時に発生する可能性があるメモリリークを削除しました。（バグ #31940549） ● Ubuntuでのコンパイルの失敗が修正されました。（バグ #31930934、バグ #100938） ● 部分的な取り消し情報を格納するために使用されるメモリは、多数のステートメントを実行したセッションで過度に大きくなる可能性がありました。（バグ #31919448） ● サーバーは、WHERE_CONDITIONの最適化の全てのケースを正しく処理しませんでした。（バグ #31905199） ● FLUSH TABLES WITH READ LOCKは、他のセッションがSHOW TABLE STATUSを実行するのをブロックする可能性がありました。（バグ #31894662） ● MIN()およびMAX()が、時間値またはJSON値を引数として持つウィンドウ関数として使用された時に誤ってNULLを返すことがありました。（バグ #31882291） ● GRANT ... GRANT OPTION ... TOおよびGRANT ... TO .. WITH GRANT OPTIONは、サーバーログに正しく書き込まれない場合がありました。（バグ #31869146、バグ #100793） ● デバッグビルドの場合、256を超えるエントリのパーティションリストを使用するCREATE TABLEで、アサーションが発生しました。（バグ #31867653） ● init_fileシステム変数で指定されたファイル内のクエリにより、サーバーの起動に失敗する可能性がありました。（バグ #31835782） ● ハッシュ結合を実行する時、オプティマイザは負の整数値と非常に大きな符号無しの整数値の誤一致を登録する可能性がありました。（バグ #31832001、バグ #31940639、バグ #100967） ● SHOW VARIABLESは、partial_revokesシステム変数に関して誤った値を報告する可能性がありました。（バグ #31819558、バグ #100677） ● パフォーマンススキーマのuser_defined_functionsテーブルでは、UDF_LIBRARY列の値は、サービスAPIを介して登録されたユーザー定義関数に関してNULLであると想定されています。値が誤って空の文字列に設定されました。（バグ #31791754） ● サーバーの自動アップグレード手順では、latin1文字セットを使用した古いヘルプテーブルのアップグレードに失敗しました。（バグ #31789964） ● シリアル化可能または繰り返し可能読み取りトランザクション分離レベルで付与テーブルを読み取るSQLステートメントを実行すると、重複する警告が発生する可能性がありました。（バグ #31769242） ● DISTINCT集計を使用した特定のクエリ（通常、集計前に並べ替えることで解決される）では、一時テーブルを処理するロジックが重複排除を実行したという誤った想定により、サーバーはストリーミングではなく一時テーブルを使用しました。現在は、サーバーは代わりに暗黙の一意のインデックスをチェックします。これにより、より堅牢になり、不要なロジックを削除できます。（バグ #31762806） ● イベントスケジューラのイベント定義のlower_case_table_names値とスキーマ名の特定の組み合わせでは、サーバーが停止する可能性がありました。（バグ #31733090） ● あるストアド関数を別のストアド関数内から呼び出すと、フィールド解決で競合が発生し、サーバーが終了する可能性がありました。（バグ #31731334） ● udf_init()メソッドなしで定義されたユーザー定義関数は、予期しないサーバー終了を引き起こす可能性がありました。（バグ #31701219） ● secure_file_privシステム変数をNULLに設定すると、そのアクションが無効になりますが、代わりにサーバーがNULLという名前のディレクトリを作成します。（バグ #31700734、バグ #100384） ● 共有構造への不適切な同時アクセスが原因で、mysqlpumpが予期せず終了する可能性がありました。（バグ #31696241） ● コンポーネントのアンインストールおよびそのコンポーネントによってインストールされたユーザー定義関数（UDF）の登録解除は、UDFが現在使用されているかどうかと適切に同期されませんでした。（バグ #31646698） ● マルチテーブルのUPDATEまたはDELETEを実行したプリペアドステートメントの実行後のクリーンアップは、常に正しく行われたとは限りません。つまり、このようなプリペアドステートメントの最初の実行後、サーバーは、実際には行が変更されていなくても、ゼロ以外の数の行が更新されたことを報告しました。（バグ #31640267） 参照：バグ #32100210。 ● プライマリキーの拡張をサポートするエンジンの場合、キーの全長がMAX_KEY_LENGTHを超えた場合、または、キーパーツの数がMAX_REF_PARTSを超えた場合、これらの制限内に収まらないプライマリキーのキーパーツはセカンダリキーに追加されませんでしたが、プライマリキーのキーパーツは無条件にセカンダリキーの一部としてマークされました。 これにより、セカンダリキーがカバーインデックスとして扱われる状況が発生し、間違ったアクセス方法が選択されることがありました。 これは、プライマリキーのキーパーツがセカンダリキーに追加される方法を変更して、前述の制限内に収まらないものがクリアされるようにすることで修正されています。（バグ #31617858） ● MySQLが-DWITH_ICU=systemに設定されている場合、CMakeはICUライブラリのバージョンが十分に新しいことを確認するようになりました。（バグ #31600044） ● --binary-as-hexオプションを指定して呼び出されると、mysqlはNULL値を空のバイナリ文字列（0x）として表示しました。 未定義の変数を選択すると、NULLではなく空のバイナリ文字列（0x）が返されました。（バグ #31549724、バグ #31638968、バグ #100251） ● DISABLE_PSI_xxxパフォーマンススキーマ関連CMakeオプションを有効にすると、ビルドが失敗しました。（バグ #31549724） ● 一部のクエリは、internal_tmp_mem_storage_engineの値に応じて異なる結果を返しました。 この問題の根本的な原因は、ウィンドウ関数の行をバッファリングする時に、これらのバッファリングされた行を保持するメモリ内の一時テーブルのサイズが指定された制限を超える場合に、新しい一時テーブルがディスク上に作成されるという事実に関連していました。フレームバッファパーティションオフセットは、新しいパーティションの開始時に、これまでに読み取られた行の総数に設定され、一時テーブルがディスクに移動された時に使用するために特別に更新されます（これは、ウィンドウ関数の処理に必要なヒントを計算するために使用されます）。この問題は、ディスク上に一時テーブルを作成する時に新しいパーティションが開始されるという特定のケースでフレームバッファーパーティションオフセットが更新されず、誤った行が読み取られたために、発生しました。 この問題は、一時テーブルがディスクに移動されている間に新しいパーティションが開始される時はいつも、フレームバッファーパーティションオフセットを正しく更新することで修正されています。（バグ #31546816） ● ウィンドウ関数の行をバッファリングしている時に、これらのバッファリングされた行を保持するメモリ内の一時テーブルのサイズがtemptable_max_ramで指定された制限を超えると、新しい一時テーブルがディスク上に作成されます。一時テーブルの作成後、現在は一時テーブルがディスクに移動され、既存のヒントが使用できなくなるために、ウィンドウ関数の処理に使用されるヒントはリセットされる必要があります。フレームバッファの最初の行が処理されている時にディスク上に一時テーブルが作成されると、ヒントは初期化されておらず、これらの初期化されていないヒントをリセットしようとすると、サーバーが予期せず終了しました。 この問題は、フレームバッファのヒントをリセットする前に、それらが初期化されているかどうかを確認するチェックを追加することで修正されています。（バグ #31544404） ● CHANNEL_NAMEのインデックスがUSE INDEX()で無効にされた時、パフォーマンススキーマはCHANNEL_NAME列の結合に対して誤った結果を生成する可能性がありました。（バグ #31544023、バグ #99989） ● 未使用のウィンドウ定義を削除する時に、ORDER BYの一部であったサブクエリは削除されませんでした。（バグ #31518806） ● 特定のケースで、サーバーは複数ネストされたサブクエリを正しく処理しませんでした。（バグ #31472704） ● VALUESステートメントで認識される構文にはORDER BY句が含まれていますが、この句が解決されなかったため、実行エンジンで無効なデータが検出される可能性がありました。（バグ #31387510） ● サーバーが起動時に存在しない一時ディレクトリにアクセスしようとしたため、エラーが発生しました。一時ディレクトリが存在していることと、ファイルがtmpdirディレクトリに正常に作成されていることを確認するためのチェックが追加されました。（バグ #31377118） ● 冗長な並べ替えを削除している間、ウィンドウの順序付けは、別のウィンドウの順序付けが原因で行が順番に来ると予想されていたという事実のために、削除されました。その後、他のウィンドウが使用されていないために削除された場合、これにより行が順序付けされなくなりました。これは、評価中に予期されていませんでした。 現在、このような場合は、未使用のウィンドウが削除されるまで、冗長な並べ替えの削除は実行されません。さらに、ロールアップの解決は準備段階に移動されました。（バグ #31361393） ● 準同期レプリケーションのエラーは、サーバーのサブシステムタグを使用してエラーログに誤って書き込まれました。現在、これらは他のレプリケーションエラーの場合と同じように、Replのタグを使用して書き込まれるようになりました。（バグ #31327337） ● ユーザーは、自分自身に役割として自分自身を付与できました。（バグ #31222230） ● サーバーは、複数のWHERE条件（そのうちの1つは常にFALSE）が同じサブクエリを参照する場合を常に正しく処理するとは限りませんでした。（バグ #31216115） ● lower_case_table_names=2設定を使用すると、InnoDBバックグラウンドスレッドがロックキーのスキーマ名部分に間違った大文字小文字を使用したテーブルメタデータロックを取得することがあり、その結果、保護されていないメタデータと競合状態が発生しました。現在は、正しい大文字小文字が適用されるようになりました。対応するデータディクショナリオブジェクトの前にメタデータロックが解放されないようにするために、および、データディクショナリオブジェクトを取得する時にロック保護をチェックするアサーションコードを改善するために、変更も実装されました。（バグ #31165802） ● CR_UNKNOWN_ERRORがクライアントに送信された場合、例外が発生しました。（バグ #31123643） ● DOUBLE値をタイプBIT、ENUM、またはSETの値に変換すると、Undefined Behavior Sanitizer警告が生成される可能性がありました。（バグ #31019130） ● skip_name_resolveシステム変数が有効になっている場合、特定のアカウントがサーバーの起動エラーを引き起こす可能性がありました。（バグ #31018510） ● 通信パケットに不良なデータが含まれていると、クライアントプログラムが予期せず終了する可能性がありました。（バグ #30890850） ● クライアントライブラリのバッファオーバーフローが修正されました。（バグ #30885987） ● 複数値インデックスまたはその他の機能インデックスを作成する場合、インデックス自体が実際に使用されていなくても、インデックスが定義されているテーブルに対してクエリを実行すると、パフォーマンスの低下が見られました。これは、そのようなインデックスをサポートする非表示の仮想列が、クエリの各行に対して不必要に評価されたために発生しました。（バグ #30838749） 参照：この問題は、バグ #28069731のリグレッションです。 ● libcurlの依存関係に関するCMakeチェックが改善されました。（バグ #30268245） ● mysql_config_editorは、パスワード値の#をコメント文字として誤って扱いました。（バグ #29861961、バグ #95597） ● いくつかのケースでは、オプティマイザが空の文字列のハッシュ値を計算しようとしました。現在は、代わりに固定値が常に使用されます。（バグ #22588319） ● INSERT()およびRPAD()関数は、結果の文字セットを正しく設定しませんでした。（バグ #22523946、バグ #79909、バグ #31887870、バグ #100841） ● val1 BETWEEEN val2 AND val3の一部のコーナーケースが修正されました。例えば、-1 BETWEEN 9223372036854775808 AND 1はtrueを返しました。（バグ #22515857、バグ #79878） ● パフォーマンススキーマのmemory_summary_global_by_event_nameテーブルの場合、低水準点列は負の値になる可能性があり、高水準点の列は、サーバーのメモリ使用量が増加していなくても、値が増え続けていました。（バグ #22246001、バグ #79285） ● 文字列を数値に変換する際のいくつかの問題が修正されました。（バグ #19186271、バグ #73248） ● 正しく実行された特定のgroup byクエリは、WITH ROLLUPが追加された場合に期待される結果を返しませんでした。これは、10進情報がロールアップグループアイテムを介して常に正しくパイプされるとは限らず、それによりTRUNCATE()などの10進値を返す関数が誤ったタイプのデータを受信するという事実によるものでした。（バグ #101684、バグ #32179240） ● 一時テーブルを実体化するためのフィールドを作成する時（つまり、結合をソートする必要がある時）、オプティマイザはそのアイテムがコピーされる必要があるか、それとも単なる定数であるかをチェックします。これは、ある特定のケースでは正しく行われていませんでした。定数を含むビューまたは派生テーブルに対して外部結合を実行すると、アイテムがテーブルに適切に実体化されなかったため、結果にNULLが誤って発生する可能性がありました。（バグ #101622、バグ #32162862） 参照：バグ #31790217。 ● REGEXP_REPLACE()がSQLステートメントで使用された時、内部関数Regexp_engine::Replace()は、レコードの処理後にエラーコード値をリセットしませんでした。これは、次のレコードの処理に影響を及ぼし、問題を引き起こす可能性がありました。 （バグ #101256、バグ #32050219） ● 次の形式のクエリの場合、一時テーブルが作成された後、列リストが一貫性のない状態になることがあり、後で範囲外のインデックスが作成されました。 SELECT * FROM ( SELECT PI() FROM t1 AS table1, t1 AS table2 ORDER BY PI(), table1.a ) AS d1; （バグ #101012、バグ #31955761、バグ #31978439） 参照：この問題は、バグ #31790217のリグレッションです。 ● 既にソートされたデータを集計する時（一時テーブルが全く使用されていないため、ストリーミング集計の実行として知られている）、次のグループの最初の行を処理するまで、グループがいつ終了したかを判断することはできませんでした。その時点までに、出力されるグループ式は既にに上書きされていることがよくありました。 これは、以前に使用された複雑なロジックを、グループに初めて遭遇した時にグループの代表的な行を保存するというはるかに簡単な方法に置き換えることで修正され、その列は必要に応じて出力行から簡単に取得できます。（バグ #100791、バグ #27272052、バグ #31073167、バグ #31790217、バグ #31868610） ● フルテキストマッチングを使用するサブクエリは、subquery_to_derivedが有効である時に正しく実行されない可能性があり、デバッグビルドでアサートが発生する可能性がありました。（バグ #100749、バグ #31851600） ● ALTER TABLE ... CONVERT TO CHARACTER SETステートメントが実行されると、テーブル内の全てのCHAR、VARCHAR、TEXT列の文字セットが新しいCHARACTER SET値に更新されます。この変更は、複数値インデックスのARRAY列で使用される非表示のCHAR列にも適用されました。非表示の列の文字セットはmy_charset_utf8mb4_0900_binまたはバイナリのいずれかである必要があるため、サーバーのデバッグビルドでアサートが発生しました。 この問題は、前述のALTER TABLEステートメントの実行時に非表示列の文字セットをテーブルの文字セットに設定しなくなったことにより解決されました。これは、同様の状況でBLOB列に対して行われることと似ています。（バグ #99403、バグ #31301101） ● いくつかのケースで、サーバーの内部文字列変換ルーチンには、長さ指定子を使用し、科学的記数法の使用をトリガーする浮動小数点値の処理に問題がありました。（バグ #92537、バグ #101570、バグ #28691605、バグ #32144265） 参照：バグ #88256、バグ #27041543。
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.23 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-23.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。