主な変更点
■ 監査ログ関連
● CREATE USERステートメントのBY 'auth_string'句が、AS 'auth_string'句として監査ログと一般クエリログに書き込まれました。（バグ #33184550）
■ 認証関連
● 以前は、MySQLユーザーアカウントは単一の認証方法を使用してサーバーに対して認証されていました。MySQLは多要素認証（MFA）をサポートするようになりました。これにより、最大3つの認証方法を持つアカウントを作成できます。MFAサポートには、次の変更が伴います。 ・CREATE USERおよびALTER USER構文が拡張され、複数の認証方法を指定できるようになりました。 ・authentication_policyシステム変数を使用すると、使用できる要素の数と各要素に許可される認証の種類を制御することにより、MFAポリシーを確立できます。これにより、CREATE USERおよびALTER USERステートメントの認証関連の句の使用方法に制約が課せられます。 ・クライアントプログラムには、複数のパスワードを指定するための新しいコマンドラインオプション --password1、--password2、--password3があります。C APIを使用するアプリケーションの場合、mysql_options4() C API関数の新しいMYSQL_OPT_USER_PASSWORDオプションにより、同じ機能が有効になります。 さらに、MySQL Enterprise Editionは、スマートカード、セキュリティキー、生体認証リーダーなどのデバイスを使用したMySQLサーバーへの認証をサポートするようになりました。この認証方法は、Fast Identity Online（FIDO）標準に基づいており、サーバー側でauthentication_fido、クライアント側でauthentication_fido_clientのプラグインのペアを使用します。サーバー側のFIDO認証プラグインは、MySQL Enterprise Editionディストリビューションにのみ含まれています。 多要素認証では、既存のMySQL認証方法、新しいFIDO認証方法、または両方の組み合わせを使用できます。（バグ #33159968） ● 認証プラグインが認証文字列のハッシュを実行しなかった場合、BY 'auth_string'句を含むCREATE USERステートメントがエラーで失敗しました。（バグ #33125289）
■ コンパイル関連
● MySQLはC++17を使用してコンパイルできるようになりました。コンパイラのサポートには、次の最小バージョン要件が適用されます。 ・GCC 7.1またはClang 5 (Linux) ・XCode 10 (macOS) ・GCC 10 (Solaris) ・Visual Studio 2019 Update 4 (Windows) 特に、Solarisでは、GCCが唯一サポートされているコンパイラになりました。コードがクリーンアップされ、Sun Studio、Oracle Studio、およびSunProの適用と回避策が削除されました。（バグ #32907274、バグ #103757、バグ #32907475、バグ #32992125、バグ #32992242、バグ #33004840、バグ #33086882）
■ 接続管理関連
● 以前は、サーバーがクライアントを、パスワードの有効期限が切れたアカウントのクライアント接続を処理するために使用されるサンドボックスモードに制限した場合、クライアントはSETステートメントを使用できました。これは許可されなくなりました。（バグ #16369085）
■ ストレージエンジン関連
● BLACKHOLEストレージエンジンの最大キー長が1000バイトから3072バイトに増加されました（InnoDBと同じ）。（バグ #32788749、バグ #103371）
■ ファイアウォール関連
● 新しいFIREWALL_EXEMPT権限は、ユーザーをファイアウォールの制限から免除します。これは、例えば、ファイアウォールを設定するデータベース管理者にとって、設定ミスによって管理者がロックアウトされてステートメントを実行できなくなる可能性を回避するのに役立ちます。
■ キーリング関連
● keyring_hashicorpプラグイン設定の問題の診断が改善されました。（バグ #32075854）
■ パフォーマンススキーマ関連
● 監視とトラブルシューティングを支援するために、パフォーマンススキーマインストゥルメンテーションがインストゥルメントされたスレッドの名前をオペレーティングシステムにエクスポートするために使用されるようになりました。これにより、デバッガやUnix psコマンドなどのスレッド名を表示するユーティリティが、「mysqld」ではなく個別のmysqldスレッド名を表示できるようになります。この機能は、Linux、macOS、およびWindowsでのみサポートされています。
■ プラガブル認証
● Microsoft Windows：MySQLサーバーおよびLinuxを実行しているクライアントホスト用にMySQL 8.0.26で追加されたKerberos認証方法が、Windowsのクライアント側でサポートされるようになりました。これにより、Windowsで実行されているMySQLクライアントアプリケーションが、Kerberosを使用して認証するLinuxサーバーホスト上のMySQLアカウントに接続できるようになります。
■ セキュリティ関連
● OpenSSLライブラリがバンドルされているプラットフォームの場合、MySQL Server用にリンクされたOpenSSLライブラリがバージョン1.1.1lに更新されました。新しいOpenSSLバージョンで修正された問題については、https://www.openssl.org/news/cl111.txtおよびhttp://www.openssl.org/news/vulnerabilities.htmlで説明されています。（バグ #33273138、バグ #33309871）
■ サーバー管理
● 次のシステム変数のセッション値の設定は制限された操作になり、セッションユーザーは制限されたセッション変数を設定するのに十分な権限を持っている必要があります。 ・low_priority_updates ・max_delayed_threads ・max_error_count ・min_examined_row_limit ・preload_buffer_size ・select_into_buffer_size ・select_into_disk_sync_delay ・show_old_temporals
■ 空間データサポート
● ST_SymDifference()およびST_Intersection()関数で、ジオメトリ引数に地理空間参照系（SRS）を設定できるようになりました。以前は、ST_SymDifference()およびST_Intersection()は、デカルトSRSのジオメトリ引数のみをサポートしていました。
■ 追加・変更された機能
● 重要な変更：default_authentication_plugin変数は、MySQL 8.0.27で非推奨になりました。MySQLの将来のバージョンでサポートが削除される予定です。 default_authentication_plugin変数は、引き続きMySQL 8.0.27で使用されますが、多要素認証機能を備えたMySQL 8.0.27で導入された新しいauthentication_policyシステム変数と組み合わせて、それより低い優先順位で使用 されます。（バグ #27515356） ● 重要な変更：BINARY演算子は非推奨になり、MySQLの将来のリリースで削除される可能性があります。BINARYを使用すると、警告が表示されるようになりました。代わりにCAST(... AS BINARY)を使用してください。 ● 重要な変更：システム変数group_replication_components_stop_timeoutは、グループレプリケーションがシャットダウン中に各モジュールが進行中のプロセスを完了するのを待機する時間を指定します。コンポーネントのタイムアウトは、STOP GROUP_REPLICATIONステートメントが発行された後に適用されます。これは、サーバーの再起動または自動再結合中に自動的に発生します。タイムアウトは、グループレプリケーションコンポーネントを正常に停止できない状況を解決するために使用されます。これは、メンバーがエラー状態の時にグループから追放された場合、またはMySQL Enterprise Backupなどのプロセスがメンバーのテーブルにグローバルロックを保持している場合に発生する可能性があります。このような状況では、メンバーはアプライヤースレッドを停止したり、分散リカバリプロセスを完了して再参加したりすることはできません。STOP GROUP_REPLICATIONステートメントは、状況が解決されるか（例えば、ロックが解放されることによって）、コンポーネントのタイムアウトが期限切れになり、モジュールがステータスに関係なくシャットダウンされるまで完了しません。 以前は、タイムアウト値のデフォルトは31536000秒（365日）でしたが、これは今説明したような状況では役に立ちませんでした。新しいデフォルト値は300秒です。そのため、グループレプリケーションコンポーネントは、5分より前に状況が解決されない場合、5分後に停止され、メンバーを再起動して再参加できます。 参照：バグ #31460690、バグ #31648211、バグ #32309647。 ● レプリケーション：レプリカサーバーでマルチスレッドがデフォルトで有効になりました。マルチスレッドアプライヤーには、トランザクションを並行して実行する多数のアプライヤースレッドがあります。この動作により、ソースとレプリカの間に一時的な相違を引き起こす可能性のある不要なレプリケーションラグの多くのケースを回避できます。 マルチスレッド動作を生成するためには、次のデフォルトのサーバー設定が使用されます。 ・replica_parallel_workers=4。この設定により、マルチスレッドが有効になり、レプリカ上に4つのアプライヤースレッドと、それらを管理するためのコーディネータースレッドが作成されます。複数のレプリケーションチャネルを使用している場合、各チャネルにはこの数のスレッドがあります。4つのアプライヤースレッドが基本レベルの並列処理を提供し、設定を変更して最大1024のアプライヤースレッドを指定できます。 ・replica_preserve_commit_order=1。この設定により、トランザクションはレプリカのリレーログに表示されるのと同じ順序でレプリカ上で外部化されるため、レプリカはマスターが存在しない状態になることは決してなく、リレーログから実行されたトランザクションのシーケンスにギャップはありません。 ・replica_parallel_type=LOGICAL_CLOCK。この設定は、レプリケーションソースサーバーでコミットされた同じバイナリロググループの一部であるトランザクションがレプリカで並行して適用されることを指定します。これは、replica_preserve_commit_order=1が設定されている場合に必要です。 新しいデフォルトを上書きし、レプリカサーバーのマルチスレッドを無効にするためには、replica_parallel_workers=0を指定します。この設定により、並列実行が無効になり、レプリカに単一のアプライヤースレッドが与えられ、コーディネータースレッドは与えられません。この設定を適用すると、replica_parallel_typeオプションとreplica_preserve_commit_orderオプションは無効になり、無視されます。 ● レプリケーション：以前のリリースでは、グループレプリケーションは、TLS/SSLや着信グループ通信システム（GCS）接続の許可リストの使用を含む、セキュリティプロトコルの独自の実装を使用して、メンバー間のグループ通信接続と分散リカバリ接続を保護していました。レプリケーショングループは、グループレプリケーションの実装の代わりにMySQLサーバー独自の接続セキュリティを使用できるようになりました。MySQLプロトコルを使用するということは、許可リストの代わりにグループへのアクセスを許可（または取り消し）するためにユーザー認証の標準的な方法を使用できること、およびサーバーのプロトコルの最新機能がリリース時に常に利用可能であることを意味します。MySQL通信スタックが使用されている場合、ネットワーク名前空間はグループレプリケーションでサポートされます。 グループレプリケーションの実装の代わりにMySQLサーバーの接続セキュリティ管理の実装を使用するためには、新しいシステム変数group_replication_communication_stackをMYSQLに設定します。さらに、各グループメンバーのgroup_replication_local_addressによって設定されたネットワークアドレスは、bind_addressで指定されているとおり、MySQLサーバーがリッスンしているIPアドレスとポートの1つに変更する必要があります。ネットワーク名前空間が使用される場合、group_replication_recoveryチャネルのCHANGE REPLICATION SOURCE TOステートメントを使用して、これを設定する必要があります。 認証は、CHANGE REPLICATION SOURCE TOを使用して設定されたとおり、グループレプリケーションが分散リカバリに使用する既存のレプリケーションユーザーアカウントを使用して実行され、このユーザーは新しいGROUP_REPLICATION_STREAM権限を付与される必要があります。接続のTLS/SSL設定は、分散リカバリを保護するためのグループレプリケーションの既存の設定に加えて、TLS/SSLをグループ通信で有効にするか無効にするかを指定するgroup_replication_ssl_modeシステム変数から取得されます。これらの設定がまだ行われていない場合は、設定する必要があります。通信の問題を回避するためには、これらの全ての設定を全てのグループメンバーで同じにする必要があります。 ● オプションファイルのincludeまたはincludedirディレクティブの処理中に問題が発生したプログラムは、エラーの原因についてより多くの情報を提供するエラーメッセージを生成するようになりました。（バグ #32798288、バグ #103397） ● サポートされている全てのプラットフォームで、thread_stackシステム変数のデフォルト値が1048576に増加されました。（バグ #103912、バグ #32965326） 参照：バグ #32934187。 ● MySQL Server Dockerコンテナの起動時にサーバーオプション --default-time-zoneを使用して、サーバーのデフォルトのタイムゾーンを設定できるようになりました。以前は、オプションが使用された場合、コンテナは開始できませんでした。 ● GTIDベースのレプリケーションがレプリカサーバーで使用されている場合、レプリケーションアプライヤースレッドとレシーバースレッドは、引き続き、代替のバイナリログファイル位置ベースのレプリケーションで使用されるように、バイナリログファイル名とファイル位置を追跡し、それらに依存します。CHANGE REPLICATION SOURCE TOステートメントの新しいオプションGTID_ONLYは、レプリケーションメタデータリポジトリからファイル名とファイル位置の永続性を削除します。この設定のレプリケーションチャネルの場合、メモリ内のファイル位置は引き続き追跡され、デバッグ目的でエラーメッセージやSHOW REPLICA STATUSステートメントなどのインターフェイスを介してファイル位置を監視できます（それらが古くなっている場合は無効として表示されます）。ただし、トランザクションのキューイングやアプリケーションプロセスなど、GTIDベースのレプリケーションで実際に必要とされない状況では、ファイル位置を永続化して確認するために必要な書き込みと読み取りは回避されます。 GTID_ONLYオプションは、非同期レプリケーションチャネルではデフォルトで無効になっていますが、グループレプリケーションチャネルではデフォルトで有効になっており、無効にすることはできません。レプリケーションチャネルにGTID_ONLY = 1を設定するためには、サーバーでGTIDが使用されている必要があり（gtid_mode = ON）、ソースで行ベースのバイナリロギングが使用されている必要があります（ステートメントベースのレプリケーションはサポートされていません）。CHANGE REPLICATION SOURCE TOのオプション REQUIRE_ROW_FORMATおよびSOURCE_AUTO_POSITIONは、レプリケーションチャネルに対してそれぞれ1に設定する必要があります。GTID_ONLYが1に設定されている時、そのシステム変数がサーバーに対してゼロに設定されている場合、レプリカはreplica_parallel_workers=1を使用します。そのため、技術的には常にマルチスレッドアプライヤーです。これは、マルチスレッドアプライヤーがレプリケーションメタデータリポジトリではなく保存された位置を使用して、再適用する必要のあるトランザクションの開始を見つけるためです。 ● MySQLレプリケーションの非同期接続フェイルオーバーメカニズムにより、管理されたレプリケーショングループの一部であるレプリカが、現在のレシーバー（グループのプライマリ）に障害が発生した場合に、送信者に自動的に再接続できるようになりました。この新機能は、シングルプライマリモードで設定されたグループのグループレプリケーションで機能します。そのグループのプライマリは、SOURCE_CONNECTION_AUTO_FAILOVERがONに設定されたレプリケーションチャネルを持つレプリカです。この状況では、この機能はデフォルトでグループで動作しますが、group_replication_disable_member_action()関数を使用して新しいメンバーアクションmysql_start_failover_channels_if_primaryを無効にすることで、グループに対してこの機能を無効にできます。この機能は、送信者のグループと受信者のグループが、一部のメンバーが一時的に利用できない場合でも相互に同期を維持するように設計されています。また、受信者のグループを、管理対象グループの一部ではない1つ以上の送信者と同期します。レプリケーショングループの一部ではないレプリカは、この機能を使用できません。 この機能を設定するためには、レプリケーションチャネル、およびそのチャネルのレプリケーションユーザーアカウントとパスワードを、レプリケーショングループ内の全てのメンバーサーバーと、新しく参加するメンバーに設定する必要があります。これは、CHANGE REPLICATION SOURCE TOステートメントを使用して実行できます。または、MySQLのクローン機能を使用して新しいサーバーがプロビジョニングされている場合、これは全て自動的に行われます。チャネルのSOURCE_CONNECTION_AUTO_FAILOVER設定は、グループメンバーが参加した時、およびそれが変更された場合、プライマリからグループメンバーにブロードキャストされます。ソースリストは、メンバーが参加した時、またはそれが更新された時に、全てのメンバーにブロードキャストされます。プライマリがオフラインまたはエラー状態になった場合、グループ用に選択された新しいプライマリには、ソースリストとチャネル設定がすでに設定されており、ソースとの交換用非同期レプリケーション接続が確立されます。 管理者が非同期接続フェイルオーバーメカニズムに関連する全ての設定を削除できるように、新しい関数asynchronous_connection_failover_reset()も提供されています。この機能を使用して、管理対象グループで使用されなくなったサーバーをクリーンアップします。 ● グループレプリケーションのグループ通信エンジン（XCom、Paxosバリアント）は、デフォルトでグループの全てのメンバーをリーダーとして使用します。グループレプリケーション通信プロトコルのバージョンが8.0.27以降に設定されている場合、グループがシングルプライマリモードの時に、グループ通信エンジンが単一のリーダーを使用してコンセンサスを推進できるようになりました。単一のコンセンサスリーダーと連携することで、特にグループのセカンダリメンバーの一部が現在到達不能である場合に、シングルプライマリモードでのパフォーマンスと回復力が向上します。 単一のコンセンサスリーダーはグループのプライマリと同じ場所に配置され、新しいプライマリが選出されると変更されます。パフォーマンススキーマテーブル replication_group_communication_informationは、優先および実際のコンセンサスリーダー、または全てのメンバーがリーダーとして使用されている場合は複数のリーダー、通信プロトコルバージョン、および書き込みの同時実行性を示します。 新しい動作を有効にするためには、システム変数 group_replication_paxos_single_leaderをONに設定します（デフォルトはOFFです）。グループレプリケーションがマルチプライマリモードで実行されている場合、または以前の通信プロトコルバージョンで実行されている場合、または、group_replication_paxos_single_leaderがOFFに設定されている場合、グループ通信エンジンはグループの全てのメンバーをリーダーとして使用して動作します。 レプリケーショングループのメンバーを新しいMySQLServerリリースに手動でアップグレードする場合、グループの通信プロトコルバージョンが一致するように自動的にアップグレードされないことに注意してください。以前のリリースでメンバーをサポートする必要がなくなった場合は、group_replication_set_communication_protocol()関数を使用して、通信プロトコルのバージョンを、メンバーをアップグレードした新しいMySQLサーバーのバージョンに設定できます。MySQL InnoDB Clusterは、その機能を使用して作成されたレプリケーショングループの通信プロトコルバージョンを自動的に管理します。 ● オンラインDDL操作の場合、通常、ストレージがボトルネックになります。今回の変更により、CPU使用率とインデックス作成が改善されました。スキャンフェーズのCPU使用率が改善され、インデックスを連続してではなく同時に作成できるようになりました。また、ユーザーが設定したメモリ設定の制限を尊重するために、メモリ管理も強化されています。 新しい innodb_ddl_buffer_size変数は、DDL操作の最大バッファサイズを定義します。デフォルト設定は1048576バイト（約1MB）です。バッファサイズ制限を定義すると、セカンダリインデックスを作成または再構築するオンラインDDL操作の潜在的なメモリ不足エラーを回避できます。 ● クローンプラグインは、クローン操作の進行中に、ドナーMySQLサーバーインスタンスでの同時DDL操作を許可するようになりました。以前は、クローン作成操作中にバックアップロックが保持されていたため、ドナーでの同時DDLが妨げられていました。クローン操作中にドナーで同時DDLをブロックする以前の動作に戻すためには、clone_block_ddl変数を有効にします。 ● internal_tmp_mem_storage_engine変数のセッション値を設定するためには、SESSION_VARIABLES_ADMINまたはSYSTEM_VARIABLES_ADMIN権限が必要になりました。
■ 主なバグ修正
● 互換性のない変更：ビューの全てのSELECTステートメントについて、クエリダイジェストはビュー定義に基づいていました。その結果、異なるクエリは同じダイジェストを持ち、パフォーマンススキーマテーブル events_statements_summary_by_digestに集約されたため、そのテーブルの統計は、個別のSELECTステートメントを区別するために使用できませんでした。 ビューの各SELECTステートメントのクエリダイジェストは、ビュー定義ではなくSELECTに基づくようになりました。これにより、events_statements_summary_by_digestテーブル内の個別のSELECTステートメントを区別することができます。ただし、クエリダイジェストを使用するツールでは、この変更を考慮して調整が必要になる場合があります。例えば、MySQL Enterprise Firewallおよびクエリ書き換えプラグインはクエリダイジェストに依存しており、ビューに関連付けられているそれらの既存のルールを更新する必要がある場合があります。（バグ #27540213、バグ #89559、バグ #31761802） ● 重要な変更：EXPLAIN FORMAT=TREEは、インデックススキャンがカバーインデックスを使用するかどうかを表示するようになりました。したがって、テーブル／クラスター化インデックスから他の列を検索する必要はありません。例えば、idx1がカバーインデックスである場合、idx1を使用したt1での古い出力インデックススキャンは、idx1を使用したt1でのカバーインデックススキャンとして表示されるようになりました。以前は、この情報はFORMAT=TRADITIONALおよびFORMAT=JSONの場合にのみ表示されていました。 この修正により、全文検索に使用される表現も改善され、この変更に対応できるようになります。例えば、t1での古い出力インデックス付き全文検索（カバーする場合とカバーしない場合の両方で同じ）は、カバーするインデックスがない場合のt1での全文インデックス検索と、カバーリングインデックスが使用されている場合のt1での全文カバーインデックス検索になりました。（バグ #32825235） ● InnoDB：innodb_open_filesの制限を一時的に超えた時に、エラーログに過剰な数のメモが書き込まれました。（バグ #33343690） ● InnoDB：インプレースDDL操作で、変更された全てのページをフラッシュできませんでした。（バグ #33290335、バグ #33238133） ● InnoDB：サブパーティション化されたInnoDBテーブルからHeatWaveにデータをロードする時に、並列スキャンが誤ったパーティションIDを返しました。（バグ #33276021） ● InnoDB：os_event構造でのメモリ使用量を減らすために、InnoDBソースの未使用のos_event::event_iterフィールドが削除されました。(Bug #33252468) ● InnoDB：Windowsでビルドエラーを引き起こすClangの問題の回避策が実装されました（Bugzilla ? バグ 51538）。 （バグ #33217633） ● InnoDB：srv_purge_threadスレッドとsrv_worker_threadスレッドがperformance_schema.threadsテーブルで複製されました。 （バグ #33209066、バグ #104575） ● InnoDB：アクティブなトランザクションによる使用中にUNDOテーブルスペースが切り捨てられると、アサーションエラーが発生しました。トランザクションは完了として時期尚早にマークされ、切り捨て操作が可能になりました。（バグ #33162828） ● InnoDB：同時DMLがプライマリキーを変更するパーティションテーブルからHeatWaveにデータをロードすると、ロードコールバックで報告されたパーティションIDが一部のレコードで正しくないことが判明しました。（バグ #33139692） ● InnoDB：InnoDBソースのMY_ATTRIBUTE((noreturn))およびMY_ATTRIBUTE((unused))のインスタンスは、C++17 [[noreturn]]および[[maybe_unused]]属性に置き換えられました。（バグ #33112971） ● InnoDB：各バッファープールブロックには、block->lock_hash_valフィールドが含まれています。この値のキャッシュは、バッファとロックシステムの不要な連結と不要なメモリ使用量を導入したため、不要であると判断されました。（バグ #33072415） ● InnoDB：行IDで並べ替えられた取得を使用してインデックスのマージを実行したクエリで、アサーションエラーが発生しました。スキャンされたテーブルにBLOBコンポーネントを持つプライマリキーが含まれているため、インデックスマージ用に設定されたレコードバッファを使用できませんでした。レコードバッファは、レコードの外部に格納されているBLOBの読み取りには使用できません。プライマリキー列がまだ読み取りセットに含まれていないため、レコードバッファのセットアップ時にBLOBプライマリキーが検出されませんでした。行IDで並べ替えられた取得では、必要に応じて後の段階でプライマリキーが一時的に追加されます。この問題に対処するために、プライマリキーにBLOBコンポーネントがある場合、行で並べ替えられた取得のためにレコードバッファが要求されなくなりました。（バグ #33067554） ● InnoDB：親テーブルから行を削除または更新すると、仮想列の値をNULLに設定する子テーブルに対するカスケードSET NULL操作が開始されました。仮想列の値は、基本列の値から派生している必要があります。 （バグ #33053297） ● InnoDB：ディスク容量に近づいていたシステムで、ファイル拡張子REDOログレコード（MLOG_FILE_EXTEND）の適用を伴うInnoDBリカバリ操作が失敗を引き起こす可能性がありました。（バグ #33002492） ● InnoDB：同じレコードに付与された明示的なロックの競合により、アサーションエラーが発生しました。（バグ #33000142） ● InnoDB：パージバッチの最後にLOBの最初のページを解放すると、アサーションエラーが発生しました。そのエラーは、無効なルートページ番号が原因でした。（バグ #32958624） ● InnoDB：障害の報告と解決を容易にするために、InnoDBソースのib::fatal()関数が改訂され、呼び出し元の場所が含まれるようになりました。（バグ #32957311） ● InnoDB：クローン受信者サーバーでのリカバリが次のエラーで失敗しました：Error reading encryption for innodb_undo_007。暗号化キーは、クローン操作のページコピーフェーズ中に作成された暗号化されたスペースに書き込まれませんでした。（バグ #32950216） ● InnoDB：不要な警告メッセージの生成を回避するために、InnoDBソースのfil_space_acquire()関数は、可能な場合はfil_space_acquire_silent()関数に置き換えられました。両方の関数は、テーブルスペースを取得するためにバックグラウンドスレッドによって使用されます。（バグ #32944543） ● InnoDB：InnoDB CRC32チェックサムアルゴリズムの実装が、ARMおよびx86/x64アーキテクチャで使用できるように最適化されました。（バグ #32887066） ● InnoDB：数千のテーブルがあるインスタンスでの起動は、エラーロギングサブシステムでの大量のトラフィックのために過度の時間がかかりました。（バグ #32846656） ● InnoDB：INFORMATION_SCHEMA.FILESビューに一時テーブルスペースファイルの現在のパスが表示されず、表示されるファイル名がinnodb_temp_data_file_path変数で定義されたものと異なっていました。（バグ #32840635、バグ #103553） ● InnoDB：Windowsで、fil_shardミューテックスを取得しようとしている時に、共有書き込みロックなしでファイルを開いたままにすると、fil_shardミューテックスを取得して同じファイルにアクセスしようとした別のスレッドでデッドロックが発生しました。（バグ #32808809） ● InnoDB：実行中の別のMySQL Serverインスタンスと同じInnoDBデータファイルを使用してMySQL Serverインスタンスを起動すると、初期化に失敗しました。（バグ #32777654、バグ #103338） ● InnoDB：InnoDBリカバリプロセスは、リカバリ中のデータにページ圧縮が適用されたことを認識しなかったため、REDOログの適用フェーズ中にテーブルスペースデータファイルのサイズが大きくなり、ディスクがいっぱいの状態に近づいているシステムのリカバリ障害につながる可能性がありました。（バグ #32771259） ● InnoDB：ファイルセグメントinodeのフィールドによって追跡された使用済みページの数との比較目的で使用済みページの数を計算するためにいっぱいではなかったファイルセグメントのリストをトラバースしたアサートが散発的に失敗しました。（バグ #31685095） ● InnoDB：オンラインDDL操作中に障害が発生した後、サーバーが再起動されると、トランザクションのロールバックに失敗しました。コミットされていないトランザクションのテーブルロックを復活させることができず、影響を受けるテーブルのデータディクショナリテーブルオブジェクトをロードできませんでした。 （バグ #31131530、バグ #99174） ● InnoDB：集計に一時テーブルを使用したクエリは、TempTableストレージエンジンで使用可能なメモリを使い果たし、テーブルがいっぱいであるというエラーで更新操作が失敗すしました。（バグ #31117893、バグ #99100） ● レプリケーション：グループレプリケーションの自動再結合手順中に、グループメンバーはそのステータスをRECOVERINGに設定します。グループメンバーが再参加できなかった場合は、ステータスをERRORに変更する必要がありますが、その間にビューの変更が発生した場合は、ステータスがRECOVERINGのままになる可能性がありました。自動再結合手順が失敗した後、進行中またはスタックしたビューの変更に関係なく、メンバーのステータスがERRORに設定されるようになりました。（バグ #33276418） ● レプリケーション：認証情報のガベージコレクションがグループレプリケーショングループコミュニケーションシステム（GCS）スレッドからバックグラウンドスレッドに移動されたため、ガベージコレクションの進行中にメッセージの送受信がブロックされることはありません。（バグ #33190276） ● レプリケーション：グループレプリケーションがgroup_replication_consistency = BEFORE_ON_PRIMARY_FAILOVERで設定されている場合、プライマリフェイルオーバーが発生すると、新しいプライマリが前のプライマリと同じ状態になるまでクライアント接続が保持されます。一部の監視および管理ステートメントはこの保持から免除されるため、フェイルオーバープロセス中に新しいプライマリを検査できます。 以前は、DOステートメントは保持から全面的に免除されていましたが、SELECTステートメントの場合と同様に、テーブルまたはロード可能な関数を使用しないDOステートメントのみが免除されるようになりました。（バグ #33130768） ● レプリケーション：レプリケーションアプライヤー（SQL）スレッドは、キーが見つからないというエラーでのストレージエンジンからの再試行可能なエラー（デッドロックや待機タイムアウトなど）を上書きし、トランザクションを再試行せずにレプリケーションを停止させます。これらのエラーは上書きされなくなりました。（バグ #33107663） ● レプリケーション：MySQLサーバーは、グループレプリケーションの停止または再起動中に、グループレプリケーションに関連するパフォーマンススキーマテーブルからの読み取りを誤って許可しました。関連するデータは使用されるべきではありませんでした。サーバーは、クエリを実行する前に、グループレプリケーションがOFFLINEステータスにあるか、初期化されていないかを確認するようになりました。（バグ #33085494） ● レプリケーション：グループレプリケーションがgroup_replication_consistency = BEFORE_ON_PRIMARY_FAILOVERで設定されている場合、プライマリフェイルオーバーが発生すると、新しいプライマリが前のプライマリと同じ状態になるまでクライアント接続が保持されます。一部の監視および管理ステートメントはこの保持から免除されるため、フェイルオーバープロセス中に新しいプライマリを検査できます。以前は、SHOWステートメントは保持から全面的に免除されていましたが（SHOW CREATE USERを除く）、データに依存しない（ステータスまたは設定のみに依存する）SHOWステートメントのみが免除されるようになりました。免除されたSHOWステートメントは、この機能のドキュメントに記載されています。（バグ #33082509） ● レプリケーション：グループレプリケーションの分散リカバリプロセスが進行中で、参加メンバーをドナーと同期していましたが、パフォーマンススキーマテーブルのreplication_group_member_statsテーブルは、group_replication_applierチャネルでキューに入れられた現在のトランザクション数（COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUEフィールド）で更新されませんでした。分散リカバリ中に新しいトランザクションが到着している間、カウントが追跡されるようになりましたが、分散リカバリの最初のフェーズで受信されたトランザクションを参加者が認証するまではゼロのままです。（バグ #33067441） ● レプリケーション：マルチスレッドレプリカ（replica_parallel_workersが0より大きい値に設定されているレプリカ）の場合、replica_parallel_workersが1に設定されていると、replica_preserve_commit_orderの設定は無視されるようになりました。アプライヤが1つしかない場合、トランザクションは常にレプリカのリレーログと同じ順序で実行およびコミットされます。コミット順序を保持するプロセスを無視すると、潜在的なパフォーマンスの低下を回避できます。（バグ #33048169） ● レプリケーション：CREATE USERなどのアクセス制御リスト（ACL）を参照するステートメントがグループレプリケーショングループのプライマリで実行され、トランザクションコミットが他のグループメンバーによって確認される直前にメンバーがグループに参加した場合、デッドロックが発生する可能性がありました。分散リカバリプロセスには、ACLステートメントによってロックされているACLキャッシュの読み取りロックが必要です。この状況により、ACLステートメントがタイムアウトするまでグループレプリケーションのグループコミュニケーションシステム（GCS）スレッドがブロックされ、プライマリに到達できなくなり、新しいメンバーが参加できなくなる可能性がありました。説明されている状況でのロックは、ビューの変更が完了し、ACLステートメントがコミットされた後にのみ解放されますが、ACLキャッシュロックは分散リカバリプロセスに不要になりました。したがって、グループレプリケーションがMySQL通信スタックを使用する場合のメンバー参加を含め、ACLキャッシュロックを必要とする新しい接続またはステートメントは、これを待つか、失敗して再試行する必要があります。（バグ #33025231） ● レプリケーション：タイムゾーンが設定されていないレプリカMySQL Serverインスタンスが、レプリカに不明なタイムゾーン値を設定するステートメントをレプリケートしようとした場合にアサーションが発生しました。レプリカはこの状況を正しく処理するようになりました。（バグ #32986721） ● レプリケーション：自動測位に必要なGTIDが削除された時にMySQLレプリケーションによって発行されるエラーメッセージは、状況によっては誤って割り当てられたり、スクランブルされたりする可能性がありました。（バグ #32965864） ● レプリケーション：グループレプリケーションのアプライヤモジュールを実行するスレッドが停止すると、グループトランザクションとメッセージを交換できないため、グループは正しく機能できなくなります。以前は、この状況のメンバーはONLINEステータスのままであり、内部エラーを無視していました。スレッドが停止すると、メンバーはERRORステータスに変わり、group_replication_exit_state_action システム変数で指定されたアクションを実行します。（バグ #32934479） ● レプリケーション：シャットダウンの直前またはシャットダウン中にグループメンバーがプライマリとして選出された場合、シャットダウンが原因で選出が失敗したためにサーバーをグループから離脱させようとしたプライマリ選出プロセスを待機している時に、シャットダウンプロセスがハングしました。プライマリの選出のエラー処理プロセスでは、これが考慮されるようになり、メンバーがすでにグループを離れている場合は、それ以上のアクションは実行されません。（バグ #32884709） ● レプリケーション：mysqldumpを使用して取得したダンプを復元した後、gtid_executedおよびgtid_purged GTIDセットの内容が永続化されませんでした。ダンプファイルのシーケンスが変更され、gtid_purged GTIDセットが書き込まれた後にmysqlスキーマ（mysql.gtid_executedテーブルを含む）がドロップされないようになりました。mysqldumpに新しいオプション --skip-mysql-schemaが追加され、mysqlスキーマを全く削除しないことを選択できるようになりました。（バグ #32843447） ● レプリケーション：パフォーマンススキーマテーブル replication_asynchronous_connection_failoverをクエリすると、クエリプロセス中に行が削除された場合にエラーが返される可能性がありました。この状況では、行数がゼロとして返され、クエリを再試行できます。（バグ #32701593） ● レプリケーション：状況によっては、接続圧縮を使用したレプリカが、ソースサーバーへの失われた接続を再確立できませんでした。この問題は修正されました。（バグ #32494609） ● レプリケーション：MySQL 8.0.22以降、レプリケーションソースサーバーはTRUNCATE TABLEステートメントをバイナリログに書き込み、サーバーの再起動後に初めて使用されるMEMORYテーブルを空にするようにレプリカに通知します。以前は、ステートメントがログに記録されたスレッドがグローバルスレッドマネージャーに登録されていなかったため、グループレプリケーションはそれを確認できませんでした。この問題は修正されました。（バグ #32355801） ● JSON：MySQL 8.0.23で行われたことに加えて、JSON関数のエラー処理にさらに改善が加えられました。（バグ #32864910） 参照：バグ #31856260。 ● JSON：MySQLでは列名は大文字と小文字を区別しませんが、JSON_TABLE()は、名前が大文字と小文字のみ異なる場合に重複する列名を許可しました。 この関数は、大文字と小文字を区別しない方法で列名を比較するようになりました。（バグ #102824、バグ #32591074） ● EL6でのビルドの場合のように、MySQLがOpenSSL 1.0.1に対してリンクされている場合、MySQLクライアントライブラリがメモリリークの原因となる可能性がありました。（バグ #33335046） ● 正規表現関数は、式またはパターンをICU正規表現エンジンに適した文字セットに変換できない場合にエラーを報告するようになりました。 さらに、いくつかのジオメトリ関数のエラーチェックが改善されました。（バグ #33290245） ● 暗黙的にグループ化されたクエリは、それらの値をインデックスから簡単に取得できる場合、最適化中に集計を計算することがあります。述部がNO PAD照合で宣言された列を参照した場合、その述部はPAD SPACEセマンティクスを使用して評価される可能性があるため、誤った結果が返されます。これは、重要でない末尾のスペースをチェックする内部関数が、全ての非バイナリ照合にPAD SPACEセマンティクスがあると想定したためです。これは、MySQL 5.7に当てはまりますが、デフォルトの照合（utf8mb4_0900_ai_ci）を含むPADセマンティクスを持たない多くの照合を追加したMySQL 8.0には当てはまりません。 このような場合、照合のパディング属性を明示的にチェックすることでこれを修正します。（バグ #33282123） ● フルテキストインデックスなしで定義されたテーブルで実行されたMATCH() AGAINST()句を含む共通テーブル式を含むクエリは、アサーションエラーを発生させました。（バグ #33264864） ● いくつかのパフォーマンススキーマテーブルには、デフォルトのsql_mode値 NO_ZERO_IN_DATEおよびNO_ZERO_DATEと競合するデフォルトのタイムスタンプ値 0（ゼロ）が含まれていました。 例えば、このようなパフォーマンススキーマテーブルに基づいて新しいテーブルを作成しようとすると、次のようなエラーが発生しました。ERROR 1067 (42000): Invalid default value for 'FIRST_SEEN'。 デフォルトのタイムスタンプ値は、次の表から削除されました。 ・performance_schema.events_errors_summary_by_account_by_error ・performance_schema.events_errors_summary_by_host_by_error ・performance_schema.events_errors_summary_by_thread_by_error ・performance_schema.events_errors_summary_by_user_by_error ・performance_schema.events_errors_summary_global_by_error ・performance_schema.events_statements_summary_by_digest ・performance_schema.host_cache ・performance_schema.replication_applier_filters ・performance_schema.replication_applier_global_filters （バグ #33240123、バグ #104643） ● NOTIFY_SOCKET環境変数への書き込みに失敗すると、エラーが発生しました。失敗した書き込みに関連するER_SYSTEMD_NOTIFY_WRITE_FAILEDエラーには2つのパラメータがありますが、1つのパラメータのみがエラーロギングルーチンに渡されました。（バグ #33239183） ● --ssl-fips-modeオプションを設定する時に、誤って型キャストされた変数が使用されました。（バグ #33223230） ● 次のスレッドは、performance_schema.threadsテーブルに存在しませんでした。 ・buf_resize_thread ・fts_optimize_thread （バグ #33214130、バグ #104582、バグ #33214136、バグ #104583） ● 内部保存関数の再帰的な呼び出すは、予期しないエラーにつながりました。（バグ #33198164） ● SPACE()関数は、特定の大きな値または符号なしの値を正しく処理しませんでした。（バグ #33180446） ● 内部のmysqld_list_fields()関数は、JSONテーブル関数を評価するために作成された一時テーブルを削除できませんでした。（バグ #33177686） ● 最小限のTARパッケージを生成するコードにより、パッケージにデバッグシンボルが追加され、ビルドが大きくなりました（約10倍）。現在、DEB/RPMコンパイラフラグは、デバッグシンボルビルドではデフォルトでオンになっており、最小サイズのリリースビルドではデフォルトでオフになっています。（バグ #33151629、バグ #104402） ● 一部のマルチテーブルDELETEステートメントがメモリをリークしていることが判明しました。（バグ #33151275） 参照：バグ #18684036。 ● サーバー内部のコピー関数の戻り値が期待どおりに処理されませんでした。（バグ #33142669） 参照：この問題は、バグ #31982292のリグレッションです。 ● YEAR値は常に正しく解釈されるとは限りませんでした。（バグ #33142669） 参照：この問題は、バグ #31994744のリグレッションです。 ● 空の範囲フレームは常に正しく処理されるとは限りませんでした。（バグ #33142418） 参照：この問題は、バグ #90300、バグ #27808099のリグレッションです。 ● ビュー内で定義された関数の解決中、関数の引数が常に正しく評価されるとは限りませんでした。（バグ #33142010） 参照：この問題は、バグ #29904087のリグレッションです。 ● デバッグビルドでは、ALTER TABLEステートメントが、後で外部キーによって参照される列の1つと同じ名前の新しい仮想列を追加した場合、エラーを生成する可能性がありました。この修正により、名前が重複している場合に仮想列が無視され、代わりに既存の非仮想列名を使用して条件がチェックされるようになりました。（バグ #33114045） ● エラーがない時にストアドプログラム命令の実行が開始されることを保証するアサート条件は、ループ内のCASEステートメントでは正しく機能しませんでした。（バグ #33079184） ● デバッグビルドでは、UPDATE HISTOGRAM句を指定したANALYZE TABLEは、診断領域を正常にクリアした後、成功値ではなく、失敗した値を呼び出し元に返す可能性がありました。（バグ #33079073） ● mecab_charsetシステムステータス変数は、その値をutf8ではなくutf8mb4として報告するようになりました。それは非推奨です。（バグ #33078623） ● デバッグビルドでは、MySQL Enterprise Encryption UDFはNULLを返す時にnull許容フラグを設定しませんでした。（バグ #33077931） ● プランロックが有効な時に、範囲オプティマイザが呼び出されることがありました。範囲オプティマイザはそれ自体を呼び出すことができるため、これにより問題が発生しましたが、プランロックでは再帰が許可されていません。（バグ #33076462） 参照：この問題は、バグ #18684036のリグレッションです。 ● CAST()およびDEFAULT()は、格納されたルーチン内で使用される場合、常に正しく処理されるとは限りませんでした。（バグ #33075828） ● 評価中に一時的な文字列バッファを使用する文字列関数は、予期しないシャットダウンにつながる可能性がありました。（バグ #33073951） ● ホスト名をIPアドレスに解決できなかった後に表示されるエラーメッセージには、意味のあるerrno値が含まれていませんでした。現在、メッセージでは(0)の代わりにEAI_NONAMEを示す(-2)が返されます。（バグ #33064143） ● CREATE TABLE t SELECT 1などのステートメントは、binlog_formatの値がROWに設定され、かつsql_modeがANSIモードの場合に、バイナリログに誤って書き込まれるInnoDBテーブルを作成しました。その結果、ステートメントのレプリケーションがレプリカでのエラーで失敗しました。このようなバイナリログにmysqlbinlogユーティリティを適用することも失敗する可能性がありました。 アトミックCREATE ... SELECTは、START TRANSACTIONと呼ばれるCREATE TABLEに新しい句を追加することによって実装されました。ただし、ANSIモードが有効になっている場合、この句は追加されませんでした。これにより、トランザクションの途中で通常の暗黙的にコミットされたCREATE TABLEが実行され、トランザクションが割り当てられたGTIDを持つ場合、GTIDモードでエラーが発生しました。この問題は、新しい句からSQLモードの依存関係を削除することで修正されています。（バグ #33064062、バグ #104153） ● 不正な形式のISO8601タイムスタンプを含むログファイルが正しく処理されませんでした。（バグ #33060440） ● 以前はutf8を参照していた文字列変換警告が、代わりにutf8mb3を参照するようになりました。（バグ #33059330） ● Enterprise Linux 8（およびFedora）の場合、fprofile.cmakeでREPRODUCIBLE_BUILDを無効にすることにより、debuginfo RPMSパッケージを修正しました。（バグ #33037380） ● EXPLAIN FORMAT=TREEは、範囲オプティマイザによって生成されたスキャンに関して以前に表示されていたよりも正確な情報を表示するようになりました。特に、サブイテレータが明示的に表示されるようになり、EXPLAIN ANALYZEで適切なタイミングが設定されます。インデックス範囲スキャンで、スキャンされている実際の範囲が表示されるようになりました。出力の説明も以前よりユーザーフレンドリーになっています。例えば、DISTINCTを使用したクエリに対して表示されるindex_for_group_byは、重複排除のためのインデックススキップスキャンに置き換えられます。 さらに、読み取り範囲交差スキャンの行数推定の不正確さの原因となる丸め誤差エラーが修正され、インデックス範囲スキャンのオプティマイザトレースで、InnoDBプライマリキーの暗黙的なキー部分が使用された時に正しく表示されるようになりました。（バグ #33037007、バグ #33062448） ● ロールアップのあるクエリの場合、グループ化列があるために式をnull許容として設定すると、その式内の全ての式をnull許容として設定し忘れ、最上位の式に対してのみ設定されていました。これは、評価中に、ロールアップによって生成されたNULLが常に正しく伝播されるとは限らないことを意味しました。これを修正するために、クエリでロールアップを使用する時に、グループ化列を持つ全ての式をnull許容として設定するようになりました。（バグ #33036184） ● EXPLAINの実行中に、ストリーミングノードまたはマテリアライゼーションノードを介して別のクエリブロックに入ると、このノードは実際のルートノードではなくルートとしてカウントされました。（バグ #33030136） ● sql/join_optimizer/cost_model.ccのdoubleからint64への未定義の変換を修正しました。（バグ #33024410） ● 内部関数find_in_group_list()が、ROLLUP処理中に全てのアイテムを正しく一致させませんでした。GROUP BY式にキャストを追加することでこれを修正しています。（バグ #33022742、バグ #33123934） 参照：この問題は、バグ #30969045のリグレッションです。 ● MySQLクライアントライブラリでメモリ割り当てが成功するかどうかのテストが欠落していると、クライアントが終了する可能性があります。（バグ #33019026） ● プリペアドステートメントからの監査ログ関数呼び出しにより、エラーが発生しました。（バグ #33016004） ● 新しい名前が機能インデックスの既存の非表示列で使用されている名前と衝突しないようにするために、!hidden!で始まる列名を追加しないでください。生成された非表示の列名は、MD5()によって生成された名前をサポートしない環境に機能インデックスの使用を拡張する次の新しい形式になりました。 !hidden!index_name!key_part_number!counter その名前の列がテーブルに既に存在しない限り、生成された名前のカウンター値はゼロです。この場合、名前が一意になるまで値が増分されます。（バグ #32983024） ● sql_help.ccから範囲オプティマイザへの不要なハードコードされた依存関係を削除しました。（バグ #32976042） ● ウィンドウ関数の実行中にバッファスペースの割り当てが不十分な場合、アサーションが発生する可能性がありました。（バグ #32975889） ● ハッシュ結合下でテーブルのリストを見つける時、ZERO_ROWSイテレータの下でも非表示になっているテーブルのリストは考慮されませんでした。これにより、NULL行フラグが正しく設定されない可能性があり、weedoutがそれらの行IDを保存する時にも問題が発生しました。（バグ #32975168） ● gen_dictionary()、gen_range()、およびgen_rnd_pan()のデータマスキング関数は、時間的に近接して複数回実行された場合、それぞれ同じ値を生成する可能性がありました。（バグ #32970772） ● 一般的なテーブル式の解決に使用される一時テーブルの作成と削除、およびサブクエリ内でのテーブル参照の作成は、常に正しく管理されているとは限りませんでした。（バグ #32962511） ● mysqlクライアントで--binary-as-hexオプションを有効になっている時、空の文字列がNULLではなく0xとして出力されるようになりました。（バグ #32961656、バグ #103906） ● リゾルバは通常、ステートメントでエラーが発生した後、分析を終了し、終了します。重複する列分析の場合、リゾルバは列リストの最後まで続けて、診断オブジェクトに複数のエラーメッセージを追加する可能性がありました。（バグ #32960158） ● スカラーサブクエリが複数の行を返した場合、結果のエラーは常に正しく処理されるとは限りませんでした。（バグ #32956779） ● 生成された列を含むテーブルを作成した後にサーバーのSQLモードを変更すると、誤ったメッセージがエラーログに書き込まれる可能性がありました。（バグ #32954466） ● Windowsでは、マニフェストファイルの読み取りが失敗する可能性がありました。（バグ #32950322） ● IN()リストの値の評価は、エラーが発生してもすぐには停止せず、アサートエラーにつながりました。このような場合、エラーが発生するとすぐに評価を停止することでこれを修正しています。（バグ #32942328） ● 2つのNULL不可の値の比較を文字列として評価している時にエラーが発生した場合、比較演算子のメタデータによると結果がNULL不可であったとしても、比較の結果はNULLに設定されました。エラーはユーザーに正しく返されましたが、デバッグモードで実行している時に、この不整合によってアサーションが発生しました。 これは、所有者がnull可能でない場合に、Arg_comparatorがその所有者をNULLに設定しないようにすることで修正されています。（バグ #32942327） ● アップグレード操作中に実行されたSQLスクリプトで参照された未設定の変数により、エラーが発生しました。（バグ #32939819） ● ファイルソート操作での不適切なエラー伝播により、アサーションが発生する可能性がありました。（バグ #32932969） ● ウィンドウ式のビット関数は、ビットマスクの実行時サイズがその解決時間サイズより大きくないことをアサートします。以下にリストされている、このルールの違反がいくつか見つかりました。 ・ENCRYPT()は、結果の最大サイズを誤って計算することがありました。 ・CONVERT()、CONCAT()、CONCAT_WS()、EXPORT_SET()、INSERT()、REPLACE()、およびWEIGHT_STRING()は、バイナリ文字セットの最大結果長を適切に計算しませんでした。 ・REPLACE(str, from_str, to_str)の解決中、strの一致ごとにfrom_strの全長が置き換えられると想定しましたが、from_strの長さは1文字しかないため、strをto_strの複数コピーに置き換えることができます。 ・COMPRESS()は、任意の方法で最大結果長を計算しました。現在は、代わりに、zlibライブラリのcompressBoundを使用します。 （バグ #32922688、バグ #33117410、バグ #33275424） ● 内部のWalkAndReplace()関数で、set_cmp_func()からのエラーが正しく伝播されませんでした。（バグ #32918927、バグ #33007298） 参照：この問題は、バグ #32548377のリグレッションです。 ● チャネル設定の読み取り中にRESET REPLICA ALLステートメントが使用された場合、デッドロックが発生する可能性がありました。（バグ #32906709） ● 永続変数キャッシュにアクセスする際の潜在的な競合状態が解消されました。（バグ #32901419） ● MySQLオプティマイザによって実行される定数伝播は、場合によっては、null許容ではない列への参照をnull許容式に置き換えることができました。これが発生すると、置き換えられた列参照の親アイテムのNULL可能性が間違っている場合があり、NULL可能でないアイテムが予期せずNULLを返した時に、実行中に、後でアサートエラーが発生する可能性があります。 null許容不可の列参照がnull許容式に置き換えられた場合に定数の伝播をスキップすることで、これを修正しています。（バグ #32895824） 参照：この問題は、バグ #32371039のリグレッションです。 ● クエリで提供された列名は、照合の詳細が異なる場合がありました。または、名前がクエリで式エイリアスとして提供されたために、今もディクショナリの列名と一致する場合があります。クエリ出力には、ディクショナリの列名（AAAなど）ではなく、クエリで指定された列名（aaaなど）が含まれていました。（バグ #32892045） ● サーバーのSQLモードがstrictモード以外の場合、特定の文字列関数はNULLを返し、結果が結果バッファに対して大きすぎることを示します。これにより、正しくソートされていない出力など、一貫性のない動作が発生する可能性がありました。さらに、関数LAST_INSERT_ID()およびCAST(... AS CHAR)は、全ての場合でnull可能性を適切に維持していませんでした。（バグ #32864958） ● ORDER BY、ウィンドウ関数、またはビューへの参照の一部として追加された非表示のアイテムは、暗黙的にグループ化されたクエリで常に正しく処理されるとは限りませんでした。（バグ #32863279、バグ #33079592） ● 否定の型解決では、型を整数から10進数に変換する時に適切な精度が設定されませんでした。これは、引数と同じ精度を割り当てることで修正されています。（バグ #32863037） 参照：この問題は、バグ #31348202のリグレッションです。 ● 失敗したCREATE TABLE ... SELECTステートメントの不適切なエラー伝播により、ロールバックが発生しませんでした。（バグ #32855882） ● サブクエリで使用される場合、複数のROW()を持つVALUESが常に正しく処理されるとは限りませんでした。（バグ #32851684） ● 待機タイムアウトの期限が切れた（ER_CLIENT_INTERACTION_TIMEOUT）時にMySQLサーバーがクライアントプログラムに送信するエラーパケットは、プロトコル圧縮が使用された時にパケットヘッダーで0ではなく2の誤ったシーケンス番号を使用しました。（バグ #32835205、バグ #103412） ● フルテキストインデックスを持つ複数のテーブルでの同時挿入操作により、多数のフルテキストインデックス同期要求が発生し、メモリ不足状態が発生しました。（バグ #32831765、バグ #103523） ● 以前の問題の修正は、それを冗長にし、ウィンドウ関数で使用される式から無効な結果をもたらす後続の作業に続いて、元に戻されました。（バグ #32820802） 参照：元に戻されたパッチ：バグ #26389508。 ● プリペアドステートメントでは、NULLIF()結果タイプの決定が正しくない可能性がありました。（バグ #32816305、バグ #103458） ● EXISTSを準結合に変換する場合、および、クエリにビュー参照が含まれている場合、クエリは正しく処理されませんでした。（バグ #32813550） 参照：この問題は、バグ #30671329のリグレッションです。 ● 保存されたルーチン内でのビューの作成と削除は、常に正しく処理されるとは限りませんでした。（バグ #32807430） ● 以前の問題の修正には、10進式の精度とスケールの決定方法の小さなリファクタリングが含まれていました。その後、TRUNCATE()関数の場合、精度がゼロになる（これは無効）可能性があることが明らかになりました。 ゼロの精度を1として扱うことにより、この問題を修正しています。（バグ #32802251） 参照：バグ #31348202。 ● 従来の理由により、table_path内にFilterとSortを含む複合アクセスパスを設定できます。分析を容易にし、フォーマットを改善するために、これらのEXPLAIN出力をマテリアライズアクセスパスの前に移動します。 ここでは、この変更の前後の両方で実行されるEXPLAINステートメントの例を示します。 # 以下とおりテーブルが作成されました: mysql> DROP TABLE IF EXISTS t1; Query OK, 0 rows affected (0.02 sec) mysql> CREATE TABLE t1 ( f1 INTEGER ); Query OK, 0 rows affected (0.03 sec) # 変更前: mysql> EXPLAIN FORMAT=TREE -> SELECT * FROM ( SELECT * FROM t1 LIMIT 2 OFFSET 1 ) AS alias1 -> WHERE f1 <= ANY ( SELECT f1 FROM t1 ) ORDER BY f1\G *************************** 1. row *************************** EXPLAIN: -> Sort: alias1.f1 -> Filter: <nop>((alias1.f1 <= (select #3))) (cost=2.62 rows=2) [other sub-iterators not shown] -> Table scan on alias1 (cost=2.62 rows=2) -> Materialize (cost=0.35..0.35 rows=0) -> Limit/Offset: 2/1 row(s) (cost=0.35 rows=0) -> Table scan on t1 (cost=0.35 rows=1) # 変更後: mysql> EXPLAIN FORMAT=TREE -> SELECT * FROM ( SELECT * FROM t1 LIMIT 2 OFFSET 1 ) AS alias1 -> WHERE f1 <= ANY ( SELECT f1 FROM t1 ) ORDER BY f1\G *************************** 1. row *************************** EXPLAIN: -> Sort: alias1.f1 (cost=0.35..0.35 rows=0) -> Filter: <nop>((alias1.f1 <= (select #3))) (cost=2.62 rows=2) -> Table scan on alias1 (cost=2.62 rows=2) -> Materialize (cost=0.35..0.35 rows=0) -> Limit/Offset: 2/1 row(s) (cost=0.35 rows=0) -> Table scan on t1 (cost=0.35 rows=1) -> Select #3 (subquery in condition; run only once) -> Aggregate: max(t1.f1) (cost=0.45 rows=1) -> Table scan on t1 (cost=0.35 rows=1) この変更後、table_path内の正当なアクセスパスは、TABLE_SCAN、REF、REF_OR_NULL、EQ_REF、およびALTERNATIVEのみです。（バグ #32788576、バグ #32915233） ● 定数畳み込みは、10進式を評価する時に常にエラーを正しく処理するとは限りませんでした。（バグ #32785804） ● Query_block::prepare_values()の呼び出し順序の不一致により、resolve_subquery()の後にsetup_order()が呼び出されました。つまり、サブクエリであるVALUES句の場合、setup_order（）を呼び出す前に、サブクエリが外部クエリブロックにマージされる可能性があり、それは一貫性のないデータ構造とエラーにつながりました。 以前にsetup_order()を実行することでこの問題を修正し、列が見つからない場合は、解決は中止されます。（バグ #32783943） 参照：この問題は、バグ #31387510のリグレッションです。 ● パフォーマンススキーマテーブル variables.infoで、グローバル値が永続化変数ファイルから実際にロードされた時に、システム変数 skip_slave_startがCOMPILEDとして誤ってリストされていたため、PERSISTEDが使用される必要がありました。（バグ #32640588） ● MySQLサーバーの同時ロードを伴うINFORMATION_SCHEMA.PROCESSLISTビューでのSELECTクエリにより、エラーが発生しました。（バグ #32625376）
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL Community Server 8.0.27 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-27.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。