MySQL Community Server 8.0.31 GA版（リリース日：2022年10月11日）

監査ログ関連

• audit_log_rotate()関数は、監査ログファイルのローテーションを簡素化します。以前は、監査ログファイルのローテーションでは、ファイルの名前を手動で変更し、audit_log_flush = ONに設定してファイルを閉じ、新しいログファイルを元の名前で開く必要がありました。audit_log_rotate()関数は、現在のファイルの名前を変更し、新しいファイルを作成します。監査ログファイルの名前を手動で変更する必要はなくなりました。
  audit_log_flush変数は、MySQL 8.0.31で非推奨になりました。サポートはMySQLの将来のバージョンで削除される予定です。

コンパイル関連

• v8.0.11以降はutf8mb4を使用しているため、内部パフォーマンススキーマ関数の名前を_utf8*から_utf8mb4*に変更しました。 (バグ #34351301)
  参照: バグ #27407745も参照してください。
• LLVM bug #16404で説明されているLLVM/Clang関連の整数の問題を回避するために、clang/ubsanのリンカーフラグを修正しました。 (バグ #34311325)
• 将来の互換性のために、「utf8」の代わりに「utf8mb3」を文字セット／照合に使用するようにヘルパースクリプトを更新しました。
  utf8mb3の使用法を明確にするために、utf8mb3文字セットと照合を処理するために使用される関数とデータ構造の名前を変更しました。 (バグ #34263480、バグ #34025412)
• CMakeコードを整理し、INFO_BINとINFO_SRCを簡素化しました。 (バグ #34139084)

コンポーネント関連

• 新しいコンポーネントサービスにより、サーバーコンポーネントとプラグインがローカルサーバー内でクエリできるようになりました。新しいMySQLコマンドサービスは、libmysqlのC API関数に似ていますが、クライアントにプロトコル内部を公開しない点が異なります。これらのサービスの詳細については、https://dev.mysql.com/doc/index-other.htmlで入手できるMySQL Server Doxygenのドキュメントを参照してください。検索：
  • s_mysql_mysql_command_factory
  • s_mysql_mysql_command_options
  • s_mysql_mysql_command_query
  • s_mysql_mysql_command_query_result
  • s_mysql_mysql_command_field_info
  • s_mysql_mysql_command_error_info

キーリング関連

• MySQLキーリングは、以前はサーバープラグインを使用してOracle Cloud Infrastructure Vaultキーリングのキーストア機能を実装していましたが、現在はMySQLコンポーネントインフラストラクチャを使用するように移行しています。新しいキーリングコンポーネントは、既存のkeyring_ociプラグインと類似していますが、設定が異なり、同様の設定オプションセットを使用して新しいコンポーネントを初期化すると、keyring_ociプラグインを使用して作成されたキーにアクセスできます。component_keyring_ociは、起動中に--early-plugin-loadサーバーオプションを使用してロードされないか、起動中または実行時にシステム変数を使用して設定されません。
  • 起動中に、サーバーはマニフェストファイルを使用してロードするキーリングコンポーネントを決定し、ロードされたコンポーネントは初期化時に独自の設定ファイルを参照します。
  • 実行時、ALTER INSTANCE RELOAD KEYRINGステートメントを使用すると、設定ファイルの変更後にインストール済みのキーリングコンポーネントを再設定できます。

  キーリングコンポーネントがインストールされている場合、パフォーマンススキーマの keyring_component_statusテーブルがそれに関するステータス情報を提供します。

オプティマイザ関連

• 重要な変更: MySQLオプティマイザのセット操作の内部管理が改善されました。次の効果があります。
  • UNIONと組み合わせて、括弧で囲まれたクエリ式の本体をネストできるようになりました。例えば、以前はエラー ER_NOT_SUPPORTED_YETで拒否されていた次のクエリが許可されるようになりました。
    (
    (SELECT a, b, c FROM t ORDER BY a LIMIT 3) ORDER BY b LIMIT 2
    ) ORDER BY c LIMIT 1;
  • 括弧で囲まれた式本体を折りたたむ場合、MySQLはSQL標準で指定されたセマンティクスに従うようになりました。これにより、外側の上限が内側の下限を上書きできなくなります。これは、式 (SELECT ... LIMIT 3) LIMIT 5が最大3行を返すことができることを意味します。
  • UNION DISTINCTとUNION ALLを任意の組み合わせでネストできるようになりました。

  上記の全てのケースでサポートされるネストの最大レベルは63です。これは、パーサーによって実行される簡素化またはマージに従います。 (バグ #103954)

• サブクエリで使用できないJOIN操作のテーブルを指す派生テーブルの外部参照は、（誤って）有効であると報告されましたが、派生テーブルのないそのような参照は正しく無効であると報告されました。
  関連する問題として、INSERTステートメントのVALUES句内に配置された派生テーブルへの外部参照は有効であると認識されませんでしたが、派生テーブルのない同様の参照は有効であると認識されました。このような派生テーブルへの参照は、VALUES内で受け入れられるようになりました。
  どちらの場合も、外部参照に正しい名前解決コンテキストが使用されるようにすることで問題を解決します。 (バグ #32678303、バグ #34131822)

パフォーマンススキーマ関連

• Performanceスキーマおよびsysスキーマは、MySQL 8.0.28で導入されたグローバルおよびセッションメモリ制限のメトリックを公開するようになりました。次の列がパフォーマンススキーマのテーブルに追加されました。
  • SETUP_INSTRUMENTS:
    • FLAGS
  • THREADS:
    • CONTROLLED_MEMORY
    • MAX_CONTROLLED_MEMORY
    • TOTAL_MEMORY
    • MAX_TOTAL_MEMORY
  • EVENTS_STATEMENTS_CURRENT、EVENTS_STATEMENTS_HISTORY、およびEVENTS_STATEMENTS_HISTORY_LONG:
    • MAX_CONTROLLED_MEMORY
    • MAX_TOTAL_MEMORY
  • ステートメント概要テーブル:
    • MAX_CONTROLLED_MEMORY
    • MAX_TOTAL_MEMORY
  • パフォーマンススキーマ接続テーブル:
    • MAX_SESSION_CONTROLLED_MEMORY
    • MAX_SESSION_TOTAL_MEMORY
  • PREPARED_STATEMENTS_INSTANCES:
    • MAX_CONTROLLED_MEMORY
    • MAX_TOTAL_MEMORY
  次の列がsysスキーマのSTATEMENT_ANALYSISビューおよびX$STATEMENT_ANALYSISビューに追加されました。
  • MAX_CONTROLLED_MEMORY
  • MAX_TOTAL_MEMORY
  SETUP_INSTRUMENTSテーブルのPROPERTIES列は、controlled_by_defaultフラグで更新されました。
  SETUP_INSTRUMENTSのFLAGS列の値を設定することにより、非グローバルメモリインストゥルメントを制御メモリインストゥルメントのセットに追加または削除することもできます。例えば：
  SQL> UPDATE PERFORMANCE_SCHEMA.SETUP_INTRUMENTS SET FLAGS="controlled"
  WHERE NAME='memory/sql/NET::buff';

SQL構文関連

• 重要な変更: 以前は、MySQLは、テーブル、列、ビュー、ストアドプロシージャ、またはストアドファンクションの名前として、およびテーブル、ビュー、または列のエイリアスとして、「full」の使用をサポートしていました。このリリース以降、引用符なしの識別子としてこのように「full」（大文字と小文字に関係なく）を使用することは非推奨となり、警告が発生します。これは、FULLがキーワードとして予約されているSQL標準とより密接に連携するためです。
  例えば、次に示すように、CREATE TABLEおよびDROP TABLEステートメントで警告が発生するようになりました。

  mysql> CREATE TABLE full (c1 INT, c2 INT);
  Query OK, 0 rows affected, 1 warning (0.03 sec)

  mysql> SHOW WARNINGS\G
  *************************** 1. row ***************************
  Level: Warning
  Code: 4119
  Message: Using FULL as unquoted identifier is deprecated, please use quotes or rename the identifier.
  1 row in set (0.00 sec)

  mysql> DROP TABLE full;
  Query OK, 0 rows affected, 1 warning (0.01 sec)

  mysql> SHOW WARNINGS\G
  *************************** 1. row ***************************
  Level: Warning
  Code: 4119
  Message: Using FULL as unquoted identifier is deprecated, please use quotes or rename the identifier.
  1 row in set (0.00 sec)

  警告なしでステートメントを実行するためには、次のように、それぞれのテーブル名をバッククォート文字（`）で囲みます。

  mysql> CREATE TABLE `full` (c1 INT, c2 INT);
  Query OK, 0 rows affected (0.03 sec)

  mysql> DROP TABLE `full`;
  Query OK, 0 rows affected (0.02 sec)

  値割り当ての右側でのFULLの使用は、この変更の影響を受けません。例えば、次に示すSETステートメントは引き続き有効です。

  mysql> SHOW VARIABLES LIKE '%metadata%';
  +---------------------------------------+---------+
  | Variable_name | Value |
  +---------------------------------------+---------+
  | binlog_row_metadata | MINIMAL |
  | innodb_stats_on_metadata | OFF |
  | performance_schema_max_metadata_locks | -1 |
  | resultset_metadata | FULL |
  +---------------------------------------+---------+
  4 rows in set (0.00 sec)

  mysql> SET @@global.binlog_row_metadata=FULL;
  Query OK, 0 rows affected (0.00 sec)

  mysql> SHOW VARIABLES LIKE '%metadata%';
  +---------------------------------------+-------+
  | Variable_name | Value |
  +---------------------------------------+-------+
  | binlog_row_metadata | FULL |
  | innodb_stats_on_metadata | OFF |
  | performance_schema_max_metadata_locks | -1 |
  | resultset_metadata | FULL |
  +---------------------------------------+-------+
  4 rows in set (0.00 sec)

• 列のヒストグラムをユーザー指定のJSON値に設定できるようになりました。これは、サンプリングで重要な値が除外される場合に役立ちます。これはまた、セカンダリ（レプリカ）MySQLサーバーがデータのサンプリングとヒストグラムの構築の作業を引き受けることができることを意味し、パフォーマンスに影響を与えることなくプライマリ（ソース）で使用できます。
  この機能は、ANALYZE TABLE ... UPDATE HISTOGRAMの拡張によって提供されます。次のステートメントは、テーブル tbl_nameの列 col_nameのヒストグラムをヒストグラムのJSON表現 json_dataに設定します。

  ANALYZE TABLE tbl_name
  UPDATE HISTOGRAM ON col_name
  USING DATA 'json_data'

  これは、後で情報スキーマのCOLUMN_STATISTICSテーブルのHISTOGRAM列の値をチェックすることで確認できます。
  （バグ #104040、バグ #33012389）

• このリリースで、MySQLはSQL標準のINTERSECTおよびEXCEPTテーブル演算子のサポートを追加します。
  query_a INTERSECT query_bには、両方の結果セットに含まれる行のみが含まれます。
  query_a EXCEPT query_bは、query_aの結果セットから、query_bの結果にない行を返します。
  INTERSECTとEXCEPTはどちらも、DISTINCTとALLをサポートし、どちらの場合もDISTINCTがデフォルトです。（これは UNIONの場合と同じです）。
  INTERSECTは、EXCEPTまたはUNIONの前にグループ化するため、TABLE r EXCEPT TABLE s INTERSECT TABLE tは TABLE r EXCEPT (TABLE s INTERSECT TABLE t) として評価されます。

追加・変更された機能

• 重要な変更;レプリケーション: Rewriterプラグインは、Rewriterルールのテーブルに従って SQLクエリを書き換えます。以前は、全てのクエリは、権限に関係なく全てのユーザーからのものを含めて書き換えの対象でした。また、レプリケーションアプライヤスレッドによって、MySQLサーバーのブートストラップによって、およびストレージエンジンによって実行されるような内部システムクエリも含まれていました。このMySQLリリースは、システムスレッドによって実行されるクエリや指定されたユーザーからのクエリなど、特定のクエリの書き換えをプラグインがスキップできるようにするメカニズムを提供します。
  これは、クエリが書き換えられないユーザーを示す新しい権限 SKIP_QUERY_REWRITEを実装することで実現します。新しいシステム変数 rewriter_enabled_for_threads_without_privilege_checksは、権限チェックが無効の状態で実行するスレッドの書き換えをスキップするかどうかを制御します。このようなスレッドには、アップグレードスレッド、初期化スレッド、およびPRIVILEGE_CHECKS_USERがNULLのレプリケーションスレッドが含まれます。下位互換性を維持するために、この変数のデフォルト設定は変数がONです（推奨される設定はOFFです）。
  SKIP_QUERY_REWRITEとrewriter_enabled_for_threads_without_privilege_checksの両方とも、Rewriterプラグインがインストールされている場合にのみ使用できます。
• 重要な変更: OpenSSLライブラリがバンドルされているプラットフォームでは、リンクされたMySQLサーバー用のOpenSSLライブラリがバージョン 1.1.1qに更新されました。OpenSSL バージョン 1.1.1qで修正された問題は、https://www.openssl.org/news/cl111.txtおよびhttps://www.openssl.org/news/vulnerabilities.htmlで説明されています。 (バグ #34414695)
• InnoDB: オンラインバッファプールのサイズ変更操作を監視するために、2つの新しいステータス変数が提供されます。Innodb_buffer_pool_resize_status_codeステータス変数は、オンラインバッファプールのサイズ変更操作の段階を示すステータスコードを報告します。Innodb_buffer_pool_resize_status_progressステータス変数は、各ステージの進行状況を示すパーセンテージ値を報告します。
• InnoDB: InnoDBは、インデックス構築のパフォーマンスを向上させる並列インデックス構築をサポートするようになりました。特に、ソートされたインデックスエントリをBツリーにロードする処理がマルチスレッド化されました。以前は、このアクションは単一のスレッドによって実行されていました。
• レプリケーション: レプリケーションフィルタリングが使用されている場合、レプリカは、フィルターにかけて除外されたイベントの権限チェックまたはrequire_row_format検証に関連するレプリケーションエラーを発生させなくなりました。以前は、全ての権限がアプライヤでチェックされていました。フィルターを適用する前にチェックされるものもあれば、フィルターを適用するまでチェックされないものもありました。このリリースでは、全てのレプリケーションフィルターが適用されるまで権限チェックが延期されるようになりました。さらに、このリリースより前は、require_row_formatが1に等しいかどうかのチェックが、受信側と適用側の両方で行われていました。フィルターが評価される前に、適用側だけがこのチェックを実行するようになりました。
  これにより、既存のレプリケーションフィルターを使用して検証に失敗したトランザクションを除外し、特定のユーザーがアクセスを許可されたデータベースの部分のみをレプリカが受け入れることができます（データベースのこの部分への更新が行ベースの形式でのみレプリケートされる限り）。これが望ましい別の例は、インバウンドレプリケーションユーザーがアクセスできない管理テーブルを使用するオンプレミスサービスまたはクラウドサービスからMySQLデータベースサービスに移行する場合です。
  権限チェックは、レプリカ上の重要なテーブルの更新を防ぎます。require_row_formatをチェックすると、安全でない操作の複製から保護されます。安全でない操作が存在しないことが保証されているため、一部のセッション コンテキストの初期化およびクリーンアップ アクションが不要になり、それらの操作に特権を付与する必要がなくなるので、これは権限チェックと組み合わせて使用されます。
  この作業に関連するその他の動作の変更は、次のリストに記載されます。
  • 行フォーマット検証の要求に違反するイベントが受信された時に、受信スレッドがエラーになることはなくなりました。行フォーマットの検証の要求に違反するイベントが処理され、その後レプリケーションフィルターによって除外された場合に、アプライヤスレッドがエラーになることはなくなりました。
  • 以下に挙げられているシステム変数のいずれかを設定する権限がないために除外されたクエリログイベントに対して、アプライヤスレッドがエラーを出すことはなくなりました。
    • pseudo_thread_id
    • sql_require_primary_key
    • default_table_encryption
    これは、変数の設定と、アプライヤがその設定を許可されているかどうかのチェックが、フィルタリングが行われた後にのみ実行されるようになったためです。イベントが除外された場合、アプライヤは変数を設定しようとしないため、それを行うために必要な権限があるかどうかのチェックに失敗することはありません。
  • Execute_load_queryイベントが処理され、レプリケーションフィルターが原因で除外される場合に、アプライヤスレッドが権限チェックでエラーになることはなくなりました。これは、Append_blockまたはBegin_load_queryイベントが適用され、後続のExecute_load_queryイベントが処理されてから除外される場合にも当てはまります。
  • アプライヤスレッドは、権限チェックまたはDelete_fileイベントのrequire_row_formatチェックでエラーを出さなくなりました。これらのイベントにはテーブル名またはデータベース名が含まれていないため、フィルター処理できません。そのため、それらは除外されていると想定しています。Delete_fileイベントはデータベースの状態を変更しないため、これは安全であると想定しています。
  • アプライヤスレッドは、PRIVILEGE_CHECKS_USERによって設定されたユーザーアカウントがあり、それがFILE権限を持っていない場合、または、require_row_formatが有効になっている場合に、Append_blockイベントまたはDelete_fileイベントの処理中にファイルシステムでファイルを作成または削除しなくなりました。
  • --replicate-rewrite-dbによって変更されたレプリケーションイベントの場合、全ての権限チェックが書き換えられたデータベースに適用されます。
• サーバーがリソースグループ機能をサポートしているかどうかを示すために、新しいResource_group_supportedステータス変数が追加されました。 (バグ #34264356)
• システムのcurlライブラリにリンクするのではなく、curlを含むバイナリパッケージは、curl 7.85.0を使用するようにアップグレードされました。 (バグ #34138733、バグ #34614578)
• 新しいthread_pool_transaction_delayシステム変数を使用すると、ワーカースレッドが新しいトランザクションの実行を開始するまでの遅延時間をミリ秒単位で指定できます。最大値は300000（5分）です。
  トランザクションの遅延は、リソースの競合が原因で並列トランザクションが他の操作のパフォーマンスに影響を与える場合に使用できます。例えば、並列トランザクションがインデックスの作成やオンラインバッファプールのサイズ変更操作に影響を与える場合、トランザクションの遅延を設定して、これらの操作の実行中のリソースの競合を減らすことができます。
• 新しいthread_pool_query_threads_per_groupシステム変数を使用すると、単一のクエリスレッドのデフォルトから、スレッドグループ内のクエリスレッドの数を増やすことができます。同時実行性の高いスレッドプールアルゴリズム（thread_pool_algorithm=1）を使用している場合、実行時間の長いトランザクションが原因で応答時間が遅くなる場合は、値を増やすことを検討してください。thread_pool_max_transactions_limitの値を超えることはできません。
• 以前は MySQLデータベースサービスでしか利用できなかったスレッドプールプラグイン機能が、MySQL Enterpriseエディションで利用できるようになりました。
  • thread_pool_max_transactions_limit変数は、スレッドプールプラグインによって許可されるトランザクションの最大数を定義します。トランザクション制限を定義すると、スレッドはコミットされるまでトランザクションにバインドされます。これにより、同時実行性が高い間のスループットが安定します。
  • thread_pool_dedicated_listeners変数は、各スレッドグループ内のリスナースレッドを専用にして、グループに割り当てられた接続からの着信ステートメントをリッスンします。トランザクション制限がthread_pool_max_transactions_limitによって定義されている場合、この変数を有効にする必要があります。これにより、各スレッドグループに使用可能なリスナースレッドが確保されます。
  • TP_CONNECTION_ADMIN権限により、ユーザーは権限付き接続でサーバーにアクセスできます。thread_pool_max_transactions_limitで定義された制限に達すると、新しい接続はサーバーにアクセスできなくなります。権限付き接続は、thread_pool_max_transactions_limitで定義された制限を無視し、サーバーへの接続を許可して、トランザクション制限を増やしたり、制限を削除したり、実行中のトランザクションを強制終了したりします。
• パフォーマンススキーマテーブル replication_group_communication_informationの新しいフィールド WRITE_CONSENSUS_SINGLE_LEADER_CAPABLEは、クエリ対象のメンバーでgroup_replication_paxos_single_leaderが現在OFFに設定されている場合でも、レプリケーショングループが単一のコンセンサスリーダーの使用をサポートしているかどうかを示します。グループがgroup_replication_paxos_single_leaderをONに設定して開始され、その通信プロトコルのバージョンがMySQL 8.0.27以上である場合、このフィールドは1に設定されます。
• offline_modeシステム変数の値をONに変更することによって行われるMySQL Serverのオフラインモードのアクティブ化には、SYSTEM_VARIABLES_ADMIN権限（またはこれらの権限の両方をカバーする非推奨のSUPER権限）に加えて、CONNECTION_ADMIN権限が必要になりました。ユーザーがCONNECTION_ADMIN権限を持つセッションは、オフラインモードがアクティブ化されても接続されたままになり、その権限を持つユーザーはオフラインサーバーインスタンスへの新しい接続を作成できます。新しい要件は、オフラインモードをアクティブ化できる管理者が、オフラインモードをアクティブ化することにより自分自身を不注意にロックアウトできないことを意味します。
• 読み取り専用のbuild_idシステム変数が追加されました。Linuxシステムでは、コンパイル時に160ビットのSHA1署名が生成されます。16進文字列に変換されたこの値は、ビルドの一意の識別子を提供します。この値は、起動時にサーバーログに書き込まれます。
  この変数は、Linux以外のプラットフォームではサポートされていません。

主なバグ修正

• 互換性のない変更: MySQL 8.0.14から廃止されたサービス pfs_plugin_tableは、このリリースで削除されました。
  このサービスを使用するプラグインまたはコンポーネントは、代わりに pfs_plugin_table_v1およびpfs_plugin_column_*を使用するように更新する必要があります。 (バグ #34361827)
• 重要な変更;レプリケーション: --replicate-do-dbまたは--replicate-ignore-dbが使用される度にデフォルトデータベースによってフィルター処理されるクエリログイベントには、バイナリログ形式に関係なく、XA START、XA END、XA COMMIT、および、XA ROLLBACKが含まれていました（XA PREPAREまたはXA COMMIT ONE_PHASEは含まれません）。
  これにより、次のいずれかの問題が発生する可能性があります：
  • XA STARTまたはXA ENDがフィルターで除外されると、トランザクションの最初の部分にある一連のXAステートメントが無効になり、レプリカがエラーで停止しました。
  • XA STARTおよびXA ENDが保持され、XA COMMITまたはXA ROLLBACKがフィルターで除外された場合、トランザクションはレプリカ上で無期限に準備済み状態のままになる可能性がありました。

  これらの問題のいずれかが発生するのを防ぐために、デフォルトデータベースで--replicate-do-dbまたは--replica-ignore-dbを使用して、XA START、XA END、XA COMMIT、または、XA ROLLBACKステートメントをフィルター処理しなくなりました。 (バグ #106201、バグ #33764808)

• InnoDB: ALGORITHM-INSTANTを使用して追加または削除された列の行バージョンをサポートするリリースにアップグレードした後、NULL可能列と即時追加列を持つテーブルでの即時ADD COLUMN操作中にエラーが発生しました。 (バグ #34488482)
• InnoDB: 同じALTER TABLEステートメントで仮想列を追加して列を削除すると、無効なデバッグアサーションエラーが発生しました。 (バグ #34467592)
• InnoDB: 列を削除し、既存の列の名前をその削除した列の名前に変更した後、列の物理的な位置が正しく設定されませんでした。 (バグ #34463089)
• InnoDB: mtr_t::start()で検出されたValgrindエラーが修正されました。 (バグ #34327575)
• InnoDB: 破損したパーティションテーブルでDDL操作を行うと、アサーションエラーが発生しました。 (バグ #34293555)
• InnoDB: ヒストグラムサンプリング中のインデックスブロックラッチ順序違反により、同時挿入がブロックされ、デッドロックエラーが発生する可能性がありました。 (バグ #34282448、バグ #34174927、バグ #107299)
• InnoDB: データロード操作の進行中にALTER TABLE操作を実行すると、アサーションエラーが発生しました。 (バグ #34267618)
• InnoDB: Address Sanitizer（ASAN）ビルドによって識別される、MySQLサーバーの初期化中のInnoDBメモリリークが修正されました。 (バグ #34156050)
• InnoDB: リカバリ中に、ディスクからフェッチされた暗号化されたUNDOテーブルスペースページに関連付けられたテーブルスペースオブジェクトは、ページの復号化に必要な暗号化キーを含んでいなかったため、エラーが発生しました。 (バグ #34148143)
• InnoDB: デバッグビルドで、降順のBツリースキャンでデバッグアサーションエラーが発生しました。 (バグ #34144951)
• InnoDB: innodb_redo_log_consumer_advance()関数が無効な引数の処理に失敗しました。 (バグ #34052884)
• InnoDB: ALGORITHM=INSTANTを使用して追加された列が、列を追加したDDL操作の前に作成された読み取りビューに表示されました。 (バグ #33937504)
• InnoDB: 特定のテーブルIDを持つユーザー作成テーブルを含むMySQL 5.6データディレクトリを使用してMySQLインスタンスをアップグレードしている時に障害が発生しました。そのテーブル IDの割り当てにより、MySQL 5.7からMySQL 8.0へのアップグレード中に競合するデータディクショナリテーブル IDが割り当てられました。 (バグ #33919635)
• InnoDB: 固有の一時テーブルページを含むバッファブロックがページトラバーサル中に再配置され、アサーションエラーが発生しました。 (バグ #33715694)
• InnoDB: 破棄されたテーブルスペースを持つテーブルを削除すると、アサーションエラーが発生しました。 (バグ #33232978)
• InnoDB: シャットダウンがフラッシュフェーズに達する前にページI/O読み取りが完了していないため、I/O読み取り後に完了すべき変更バッファマージがページにあった場合に、アサーションエラーが発生していました。 (バグ #33192496)
• InnoDB: dict_table_x_lock_indexes()でのインデックスラッチ順序違反により、アサーションエラーが発生しました。 (バグ #32912868)
• InnoDB: 特定のケースで、TRUNCATE TABLE操作が取得したミューテックスを解放できませんでした。 (バグ #107858、バグ #34380370)
• InnoDB: デバッグビルドで、列が即座に追加または削除されたテーブルの.cfgファイルなしでテーブルスペースをインポートすると、アサーションエラーが発生しました。 (バグ #107517、バグ #34307874)
• InnoDB: trx_undo_prev_version_build()関数の潜在的なメモリリークが修正されました。 (バグ #106952、バグ #34051207)
• InnoDB: リカバリ中にスペースの削除をやり直している時に、デバッグアサーションエラーが発生しました。 (バグ #103482、バグ #32819101)
• InnoDB: バッファプールインスタンスの数との混乱を避けるために、オブジェクトプールの数を指定するInnoDB起動メッセージが削除されました。 (バグ #80248、バグ #22653060)
• パーティショニング: ALTER TABLEステートメントがその列の文字セットを変更するように動作した時に、パーティション化されたテーブルが期待どおりに再パーティション化されませんでした。この根本的な原因は、文字セットの変更をインプレースの変更操作として実行できるかどうかを判断する際に、文字セットの変更によって影響を受ける列がテーブルのパーティション式の一部であるかどうかが考慮されていなかったことです。このような変更はテーブルの再パーティション化につながる可能性があるため、インプレースで行うことはできませんでした。文字セットの変更が計画されている場合、これがパーティション式の一部である列に影響するかどうかも確認するようになりました。そうでない場合は、インプレースで操作を実行できます。 (バグ #106884、バグ #34031693)
• レプリケーション: START REPLICAおよびSTOP REPLICAステートメントはグループレプリケーションアプライヤチャネル（group_replication_applier）に対して許可されていましたが、チャネルを手動で停止および開始すると、レプリケーショングループのONLINEメンバーがリモートトランザクションをコミットできなくなる可能性があります。グループレプリケーションの実行中は、これらのステートメントをチャネルに使用できなくなりました。 (バグ #34231291)
• レプリケーション: レプリケーション情報の処理における内部エラーを修正しました。 (バグ #34214416)
• レプリケーション: InnoDB ClusterSetで、コミット順序のデッドロックとその後の再試行が発生した場合、グループレプリケーションは、トランザクションのGTIDが既に使用されていることを示すエラーで、認証中にトランザクションをロールバックする可能性がありました。GTIDがサーバーインスタンスとグループで使用されている場合にのみ、エラーが返されるようになりました。 (バグ #34157846)
• レプリケーション: 単一のイベントがレプリカのテーブルの同じ行に複数の更新を引き起こした時、レプリカがソースに存在しないテーブルのプライマリキーを持っていた場合、その変更を適用できませんでした。レプリカのテーブルにプライマリキーが存在する場合でも、ハッシュベースの行ルックアップアルゴリズムがこの状況で動作するようになりました。 (バグ #34114296)
• レプリケーション: 1つのステートメントがレプリカ上の異なるテーブルに対して複数の書き込みイベントを生成した場合、レプリカのテーブルの追加の自動インクリメント列は、最後に生成されたイベントに対してのみクリーンアップされました。最後のイベントが追加の自動インクリメント列を持つテーブルに関係していない場合、それらはまったくクリーンアップされませんでした。クリーンアッププロセスは、複数の書き込みイベントに対して常に実行されるようになりました。 (バグ #34095290)
• レプリケーション: group_replication_force_membersシステム変数が設定され、ビュー変更の待機がタイムアウトした場合、誤解を招くエラーがクライアントに返されました。エラーおよび関連するエラーが更新されたため、システム変数に指定された値が正しくないことが示唆されなくなりました。 (バグ #34091087)
• レプリケーション: パフォーマンススキーマテーブルのreplication_applier_filtersのFILTER_RULE列に、ルールが存在しないフィルターの誤ったデータが表示されました。この状況では、テーブルに空の文字列が表示されるようになりました。 (バグ #33885484)
• レプリケーション: フラッシュエラーまたは同期エラーのまれなインスタンスで、サーバーがファイルとファイル内の位置の両方に無効な値を使用してバイナリログのエンドポイントの更新を試行し、未定義の動作につながる可能性がありました。
  この問題を解決するために、ファイルパラメータと位置パラメータの両方が有効であることがわかっている場合にのみ、内部関数 update_binlog_end_pos(binlog_file, pos)を呼び出すようになりました。 (バグ #33818238)
• レプリケーション: 無効なGTIDログイベントのSIDを使用した操作により、未定義の動作が発生することがありました。
  SIDが、無効なGTIDログイベントに属している場合でも、常に初期化されるようにすることで、この問題を解決します。 (バグ #33784022)
• レプリケーション: ステータス変数の最大長（MAX_SIZE_LOG_EVENT_STATUS）の計算が正しく実行されませんでした。
  この修正で修正された問題は次のとおりです。
  • sql_require_primary_keyとdefault_table_encryptionには2バイトが必要です（タイプID用に1、変数用に1)
  • time_zoneの最大長は、MAX_TIME_ZONE_NAME_LENGTHではなく255として計算されました
  • ユーザー変数の長さ、binlog_accessed_db_namesに格納されているデータベースIDの数、および、マイクロ秒のタイプを保存するには、追加のバイト（それぞれ）が必要です。

  　また、実際には使用されていなかったmaster_data_writtenが削除されました。 (バグ #33713071)

• レプリケーション: 32ビットプラットフォームで、binlog_expire_logs_secondsを2147483648 (231) 以上に設定すると、指定された時間が経過する前に全てのバイナリログがパージされるという影響がありました。 (バグ #33670457)
• レプリケーション: グループ設定の変更が進行中の場合、新しいメンバーは参加できません。このシナリオで発行されるエラーメッセージには、プライマリの選択、シングルプライマリモードとマルチプライマリモード間のスワップ、またはグループ通信プロトコルの変更など、進行中の操作が示されます。 (バグ #32766981)
• レプリケーション: トランザクションコミットに競合がなく、正しい順序であることを確認した後、グループレプリケーションはコミットセッションにレポートを返します。イベントスケジューラスレッドが開始された時に、グループレプリケーションがコミットセッションを見つけることができなかったため、メンバーがERROR状態になり、グループから離脱しました。コミット中のセッションを特定する手順は、イベントスケジューラスレッドの開始に使用されるように、デーモンスレッドを検索するように拡張されました。 (バグ #107635、バグ #34312482)
• レプリケーション: バイナリログの送信側スレッドがハートビートを有効にして更新を待機すると、更新シグナルを見逃すことがありました。そのため、次のシグナルが発行されてスレッドに通知されるまで変更がレプリケートされませんでした。 (バグ #104491、バグ #33176377)
• 準同期レプリケーションのパフォーマンスを向上させるためにシステム変数 replication_optimize_for_static_plugin_configが有効になっている場合、通知処理の問題によりサーバーでRAPIDプラグインを使用できませんでした。この問題は修正されました。 (バグ #34549470)
• 多くの先行ゼロを含む文字列は、それらを10進数に変換する時にオーバーフローとして誤ってマークされ、返される値が指定された精度とスケールの最大の10進数値になる原因となっていました。
  このような場合、変換前に全ての先頭のゼロを1つの0に置き換えることで、これを修正します。 (バグ #34479194)
• WindowsのWSAPoll関数とUnix系システムのpoll()関数の違いにより、Windowsのスレッドプールコードは、無効なファイル記述子またはソケットをI/Oの準備ができていると見なしました。 (バグ #34478731)
• MySQL 8.0.27以降のMySQLインスタンスがMySQL8.0.26で実行されているレプリケーショングループに参加した場合、メンバーアクション mysql_start_failover_channels_if_primaryが削除され、メンバーアクションの設定がグループの残りの部分と一致するようになりました。ただし、インスタンスがMySQL 8.0.27以降で実行するようにアップグレードされた場合、group_replication_reset_member_actions()がサーバー上で発行されてからグループがブートストラップされない限り、メンバーアクションは復元されませんでした。メンバーに参加すると、メンバーアクション mysql_start_failover_channels_if_primaryが利用可能かどうかがチェックされ、利用可能な場合はメンバーアクション設定に追加されます。 (バグ #34464526)
• クエリのSELECTリストで使用される定数式が、サーバーによって常に正しく処理されるとは限りませんでした。 (バグ #34418412)
• Json_table_column::fill_column()に欠落しているエラーチェックを追加しました。 (バグ #34416304)
• 複数の引数を受け入れる一部の文字列関数は、全ての引数を適切に処理しませんでした。 (バグ #34393009)
• UNIONの結果を保持する一時テーブル用に作成されたYEAR型のカラムは、常に正しい長さであるとは限りませんでした。 (バグ #34370933)
• ビュー（v1）が別のビュー（v2）にアクセスした場合、かつ、v2が再作成された場合、SHOW COLUMNS FROM v1は無効なビューエラーを報告しました。この問題は、ユーザーがロールを持つグローバル権限を付与され、テーブルレベルの権限が付与されていない場合にのみ発生する可能性があります。テーブルレベルの権限がない場合、グローバル権限をチェックすることで修正されます。 (バグ #34341533)
• スレッド間の競合が原因で、パフォーマンススキーマテーブル replication_group_member_actionsに対するクエリが失敗することがありました。この問題は修正されました。 (バグ #34337673)
• constテーブルを読み取る際の項目評価の後に欠落しているエラーチェックを追加しました。 (バグ #34327798)
• 特定のケースで、派生テーブルの再解析と複製が正しく処理されない場合がありました。 (バグ #34317258、バグ #34408241)
• 複数のクエリブロックが存在する場合に、set操作を使用して派生テーブルに条件をプッシュダウンすると、正しく処理されない場合がありました。 (バグ #34306361)
• RSAキーの作成中に起動に失敗したため、キーが空または不完全になりました。キーはフェイルセーフな方法で生成されるようになりました。 (バグ #34274914)
• 明示的なCOLLATE句を使用して2つの文字列値を比較する場合、これらは同じ照合を持つ必要があります。そうでない場合、比較は拒否されますが、これは常に強制されるとは限りませんでした。 (バグ #34274525)
• グループレプリケーションがサーバーインスタンスで開始された時にデッドロックが発生する可能性がありましたが、互換性のない設定などのエラーにより、メンバーはすぐに離脱しました。サービスレジストリは、この問題を回避する代替プロセスによってサービスの登録と登録解除を管理するようになりました。 (バグ #34194893)
• 予期しない構文エラーが原因で、バイナリログから読み取られたCREATE USER操作をレプリカサーバーで実行できませんでした。 (バグ #34178823)
• SQL_BIG_RESULTではなくSQL_SMALL_RESULTを使用すると、整数値に対するFLOATへのCAST操作で精度の不一致が発生することがあります。
  SQL_BIG_RESULTの場合、値はIEEE 32ビット浮動小数点値の固有の精度に従って切り捨てられました。これは正しい動作です。SQL_SMALL_RESULTでは、元の整数値の精度が維持されました。これは、値が倍精度値のみをサポートする一時テーブルにコピーされ、これらの値が後でクライアントにコピーされたために発生しました。
  このような値を一時テーブルにコピーする時に、浮動小数点値のタイプを区別することでこれを修正します。これにより、倍精度値は doubleタイプとして格納され、単精度値はfloatタイプとして格納されます。 (バグ #34167787)
• ソースコードの大部分でcodepellを実行し、コードコメントで報告されたスペルミスを修正しました。 (バグ #34163323)
• 場合によっては、呼び出される前に内部関数ポインターをチェックすると、間違ったポインターが検証されました。 (バグ #34134738)
• eq_refアクセスのアクセスパスとイテレータの両方に、順序付けられたインデックススキャンを使用するかどうかを決定するためのuse_orderメンバーがありました。eq_refは常に最大で1行を返すため、順序付けは必要ありません。したがって、use_orderはここでは何の役にも立たず、アクセスパスおよび対応するイテレータから削除されました。 (バグ #34122706)
• 単体テストのロード時にも機能するように CMakeオプション ADD_GDB_INDEXを改善しました。 (バグ #34117732)
  参照: バグ #29925009。
• 関連するCMakeオプション USE_LD_GOLDを含む、GNU 'gold'リンカーのサポートを削除しました。 (バグ #34094324)
• ディレクトリ名に特殊文字を含むMySQL 5.7のデータディレクトリ（MySQL 5.7ではスキーマディレクトリとして扱われる）に手動で作成されたディレクトリ、または、`#mysql50#`プレフィックスを使用して名前に特殊文字を使用して作成されたスキーマとテーブルは、MySQL 8.0へのアップグレード後にDDLエラーを引き起こしました。MYSQL 8.0では、オブジェクト名がデータディクショナリに追加される時に、特殊文字が疑問符（?）に置き換えられます。名前の不一致により、影響を受けるオブジェクトに対するDDL操作が失敗しました。無効なスキーマ名とテーブル名が検出された場合、アップグレードはエラーで停止するようになりました。
  MySQL 5.7では、mysqlcheckを使用して、無効なスキーマ名およびテーブル名を有効なエンコーディングに更新できます。無効な名前を特定するために、次を実行します。
  
  

  mysqlcheck --check-upgrade --all-databases

  無効な名前を修正するために、次を実行します。

  mysqlcheck --fix-db-names --fix-table-names --all-databases

  MySQL 5.7では、次のSQL構文を使用して、特殊文字を含むディレクトリ名を更新して有効なエンコーディングを使用することもできます。

  ALTER DATABASE `directory_name` UPGRADE DATA DIRECTORY NAME;

   (バグ #34066605)

• nullセーフな等号演算子（<=>）を使用する条件は、executorによって等結合条件と見なされるようになりました。このような条件を使用する述語は、等結合述語とは見なされず、結合後に評価される追加の述語と見なされます。 (バグ #34063499)
• OpenSSL 3を使用してMySQL Enterprise Encryptionコンポーネントをコンパイルするためのサポートが追加されました。 (バグ #34043029)
• ソースコードでcodepellを実行し、コードコメントで報告されたスペルミスを修正しました。 (バグ #34006439)
• GREATEST()への1つ以上の引数が一時的な値である場合、それらが関数に渡された順序が結果に影響を与える可能性がありました。 (バグ #33996054)
• IN述語を含むWHERE句の一部としてネストされたサブクエリを含む派生テーブルでのLEFT JOINを使用するSELECTは、正しくない結果を返しました。 (バグ #33971286)
• OpenSSL 3.0でのコンパイル時に、vio_ssl_write()関数およびssl_handshake_loop()関数でERR_clear_error()を呼び出すと、エラーが発生しました。 (バグ #33967647)
• サーバーは、ネストされたビューを常に期待どおりに処理するとは限りませんでした。 (バグ #33876690)
• mysqlpumpには、派生テーブル（クエリのFROM句によって生成されるテーブル）を使用するための適切な権限が与えられていない可能性があり、これらが存在する場合、ダンププロセスが停止します。派生テーブルは個別に処理され、それらに権限が設定されるようになりました。 (バグ #33866103)
• 複数のAND、OR、または、XORの条件を含むSELECTをサブクエリとして持つストアドルーチンを繰り返し実行すると、仮想メモリが過剰に消費され、最終的には枯渇する可能性がありました。 (バグ #33852530)
• EXPLAIN ANALYZEは、クエリプランの各イテレータの推定コストと経過時間に関する情報を提供します。これらの数値は累積されると予想されるため、特定のイテレータのコスト（または時間）には、このイテレータが依存する全てのイテレータのコストが含まれます。例えば、テーブル t1のテーブルスキャンとそれに続くテーブル t2でのプライマリキールックアップを使用して、t1をt2と結合する推定コストは、t1をスキャンするコストにt2でのカーディナリティルックアップのコストを加えたものよりも少なくてはなりません。
  マテリアライゼーションまたは一時テーブルを含む一部のクエリでは、これらの数値は累積されませんでした。さらに、UNION操作の結果をマテリアライズし、続いて一時（マテリアライズされた）テーブルでテーブルスキャンを実行すると、コストの見積もりが正しくありませんでした。 (バグ #33834146、バグ #34302461)
• 2つの文字列値を比較するための照合の強制は、オペランドの順序に依存していました。utf8mb4文字セットを使用する1つの文字列と、utf8mb3を使用する文字列が与えられた場合、比較は、左オペランドがutf8mb4の場合はutf8mb4照合を使用して実行され、左オペランドがutf8mb3の場合はutf8mb3を使用して実行されました。
  問題の根本は、ASCII文字列の強制に使用される特別な処理にありました。両方の文字列がリテラルであるため、ASCII文字と非ASCII文字がスキャンされ、これに従ってrepertoireプロパティが設定されました。これは、一方の文字列がASCIIとして扱われ、他方の文字列がそうではない可能性があることを意味していました。utf8mb4文字列がASCIIと見なされ、したがってutf8mb3文字列と互換性がある場合、比較の前に（誤って）変換されました。
  これは、MY_REPERTOIRE_ASCIIではなく内部のMY_CS_PUREASCIIプロパティを使用することによって修正されます。MY_CS_PUREASCIIは、実際の文字列ではなく文字セットから厳密に導出されるため、照合の決定が確定的になります。このような場合、どちらの文字列もASCIIとして識別されないため、予想どおり、比較が実行される前にutf8mb3がutf8mb4に変換されます。 (バグ #33801312)
• connect_timeout制限の範囲がフルパケット読み取りに拡張されました。 (バグ #33723597)
• イベントスケジューラがサーバー上で期待どおりに自動的に再起動することを確認するために、新しい検証が追加されました。 (バグ #33711304)
  参照: バグ #33539082。
• プリペアドステートメントをカーソルなしで実行すると、前の実行でカーソルが使用されていた場合、間違った結果が返されることがありました。この問題は、2つのクエリ結果オブジェクトを作成して保存することで解決されます。1つはカーソルありで使用し、もう1つはカーソルなしで使用します。オブジェクトはオンデマンドで作成されるため、プリペアドステートメントがカーソルありで使用されない場合、カーソル固有のクエリ結果オブジェクトは作成されません。 (バグ #33535746)
• パラメータを含むプリペアドステートメントは行の更新に失敗する可能性がありましたが、クエリとして発行された場合、同じデータを含む同じステートメントが行を更新しました。この問題を解決するためには、パラメータにデフォルトのデータタイプを割り当てます。ただし、データタイプの伝播に使用できるコンテキストがなく、文字列タイプが暗黙的に指定されるため、これは非効率的である可能性があります。この場合に、ベストプラクティスは、必要なデータタイプを提供するCAST句でそのようなパラメータ宣言をラップすることです。 (バグ #33521861)
• FEDERATEDストレージエンジンを使用するテーブルの場合、ローカルサーバーでの連続したクエリの間に、リモートサーバーの待機タイムアウト（wait_timeout設定）を超える遅延がある場合、ローカルサーバーでパケットエラーが返されました。リモートサーバーからのタイムアウトエラーがローカルサーバーによって正しく処理されるようになり、再接続してステートメントが再度実行されます。 (バグ #33500956)
• 結合の最適化中に発生する可能性のある予期しない状況を処理しました。 (バグ #31401468)
  参照: バグ #34350945。
• SET @@character_set_client = @@character_set_systemの実行後、オプティマイザヒントが正しく解析されませんでした。 (バグ #107820、バグ #34370403)
• MyISAM テーブルの列に対してブール モードで全文検索を実行するクエリは、列が文字列型でない場合にデバッグ ビルドでアサーションを引き起こしました。これは、MyISAMがbooleanモードでインデックスのないMATCH列を許可し、したがって、一定の伝播を受ける整数列も許可するという事実によるものです。MyISAM以外のストレージエンジンを使用するテーブルに対するこのようなクエリは、この問題の影響を受けませんでした。
  これは、列が文字列タイプではない場合にMATCH句で定数の伝播を無効にすることで修正されます。そのため、列参照のみが含まれていることを安全に想定できます。 (バグ #107638、バグ #34311472)
• my_time.ccのコメントのエラーを修正しました。 (バグ #107633、バグ #34308417)
• MySQL 8.0.24での接続エラー処理の変更後、max_allowed_packetの超過などのエラーによってmysqlクライアントがサーバーから切断された場合、エラーは切断を示すためにその後リセットされませんでした。その後のクエリでは、元のエラーが返され、mysqlクライアントに切断エラーがなかったため、自動再接続は行われませんでした。エラーは、切断を示し、クライアントが再接続できるように、リセットされるようになりました。 (バグ #107605、バグ #34303841)
• MySQL 8.0.29でのバグ修正後、パスワードがオプションファイルで提供された場合、ログイン時に-pオプションが指定された場合にmysqlクライアントはパスワードの入力を求めませんでした。-p オプションが指定されている場合、クライアントは常にパスワードの入力を求めるようになり、オプション ファイルから別のパスワードが入力された場合でも、指定されたパスワードが使用されます。 (バグ #107205、バグ #34134984)
• 非推奨の--ssl=offサーバーオプションを使用して暗号化された接続の使用を無効にする代替手段は、文書化されているとおり、または非推奨の警告に示されているとおりに機能していませんでした。tls_versionシステム変数を空の値（tls_version=''）に設定すると、この目的で正しく機能するようになりました。 (バグ #106459、バグ #33858646)
• BIT列の集計クエリは、ビット文字列としてフォーマットされた値を返しましたが、BINARYフラグも自動的に追加されていました。新しい検証では、BIT結果のBINARYフラグの設定をチェックしてスキップするようになりました。 (バグ #106241、バグ #33781442)
• SHOW SLAVE STATUSおよびSHOW SLAVE HOSTSは、SHOW REPLICA STATUSおよびSHOW REPLICA HOSTSの導入後、以前よりも多くのCPUを使用しました。 (バグ #105924、バグ #33684069)
• NO_SKIP_SCANヒントが、テーブルスキップスキャンに使用されない特定のインデックスを参照した場合、他の考えられる全てのインデックスも無視されるため、スキップスキャンはテーブルのどのインデックスにも使用されませんでした。
  これは、NO_SKIP_SCANヒントが全てのインデックスに適用されない場合、スキップスキャンの全ての可能なキーに対して処理が実行されなかったために発生しました。 (バグ #104670、バグ #33251616)
• WHERE列 IN（リスト）を使用するクエリは、値のリストが長くなるにつれて、ますます余分なCPU時間を消費しました。 (バグ #102037、バグ #32311183)

---

全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL Community Server 8.0.31 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-31.html

---

MySQL Editions

MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。