2022.01.31

MySQL

MySQL Community Server 8.0.28 GA版(リリース日:2022年1月18日)

主な変更点

■ 監査ログ関連

● 新しいシステム変数 audit_log_disableを使用すると、接続しているセッションと接続されているセッションの全ての監査ログを無効にできます。

■ C API関連

● コンパイラとしてClangを使用してWindowsでC APIクライアントプログラムを構築すると、未使用の変数の警告を含む様々なコンパイラの警告が返されました。(バグ #33520805、バグ #33520861)

■ 文字セットのサポート

● EXPLAIN FORMAT=TREEからの出力は、データタイプがバイナリタイプでない場合でも、複数値インデックスの16進エンコード範囲です。さらに、文字列タイプを使用する範囲も、バイナリ照合がある場合、16進エンコードされた値で出力されました。後者の問題は通常のインデックスにも影響しましたが、複数値インデックスでは常にutf8mb4_0900_bin照合を使用するため、より目立ちました。現在、16進エンコードは、バイナリ文字セットを持つ文字列タイプにのみ使用されます。非バイナリ文字セットの文字列は、EXPLAIN FORMAT=TREE出力でプレーンテキストとして出力され、特殊文字はエスケープされます。(バグ #33343948)
● CONVERT(string USING charset)は、その戻り値の正しい最大長を計算しませんでした。これは、CAST(string AS charset)に対して計算されたものと同じである必要があります。(バグ #33199145)
● 一部の関数では、解決された文字セットが最初の引数の文字セットと常に同じであるとは限りませんでした。(バグ #32668730、バグ #33238711)

■ コンパイル関連

● InnoDB:次のMSVC++のレベル4のコンパイラ警告に関連するコンパイルの問題が解決されました:C4201、C4701、C4702、C4703、C4706。以前は無効にされていたコンパイラ警告が有効になりました。(バグ #33464699)
● InnoDB:MSVC++のレベル4のコンパイラ警告が有効になりました。(バグ #33437498)
● InnoDB:Visual Studio 2019 バージョン 16.10またはバージョン 16.11を使用してMySQLのデバッグバージョンをビルドする時にアクセス違反が発生しました。その違反はSTLイテレータのバグが原因でした。(バグ #33223243)
● システムcurlライブラリにリンクするのではなくcurlを含むバイナリパッケージは、curl 7.80.0を使用するようにアップグレードされました。(バグ #33576431)

■ データタイプ関連

● このリリースでは、日付と時刻の値に関連する次の2つの問題が修正されています。
  ・'12:00:00'などのCHAR値をDATE、DATETIME、またはTIMESTAMP列に挿入すると、誤ったエラーが
   発生しました。DATE列の場合、このエラーは
   Data truncation: Incorrect date value: '2012-00-00' for column 'd' at row 1
   と同様でした。これは、バイナリプロトコルとテキストプロトコルの両方で発生しました。
  ・バイナリプロトコルを使用してDATE列またはTIME列にオフセット付きの値を挿入すると、
   間違った結果が得られました。例えば、接続タイムゾーンがGMT-5に設定されている場合、
   '2021-10-10 00:00:00.123+01:00'をTIME列に挿入すると'18:00:00'になります。
   つまり、値は接続タイムゾーンに変換されました(これは、DATEIME列に関してのみ
   実行されるべきです)。
 タイムゾーンオフセットを持つTIMESTAMP値がTIME列またはDATE列に挿入される度に、タイムゾーンオフセットを認識して調整することにより、これらを修正します。(バグ #33616957、バグ #33649009)
 参照:バグ #33539844。
● 以前の問題に対するMySQL 8.0.27の修正により、型の処理を簡素化するために、Boolean式の解決された型が符号付きのINTから符号なしのBIGINTに変更されました。しかし、無害なメタデータの変更として表示されたものが、一部のMySQL Connectorsの問題を引き起こすことが判明しました。
 現在は、メタデータの変更を元に戻し、整数の否定のmax_lengthを少なくとも2文字に調整することにより、元の問題に対して別の修正を提供します。(バグ #33516898)
 参照:この問題は、バグ #33117410のリグレッションです。
● JSONやTEXTなどの一部の列タイプのソートでは、そのサイズがそのソートの最大行のサイズの少なくとも15倍でない場合、ソートバッファが使い果たされることがありました。現在は、ソートバッファは、最大のソートキーの15倍の大きさで十分です。(バグ #103325、バグ #105532、バグ #32738705、バグ #33501541)
 参照:この問題は、バグ #30400985、バグ #30804356のリグレッションです。

■ 非推奨と削除関連

● ショートカットの、CHARACTER SET latin1のASCIIとCHARACTER SET ucs2のUNICODEは非推奨になり、MySQLの将来のバージョンで削除される予定です。これらのいずれかを使用すると、警告が発生します。代わりにCHARACTERSETを使用してください。
● 次の文字セットは、それらの照合の全てとともに非推奨になり、MySQLの後続のリリースで削除される可能性があります。
  ・ucs2
  ・macromanとmacce
  ・dec
  ・hp8
 MySQLサーバーのSQLステートメントまたは他の場所でこれらの文字セットまたはそれらの照合を使用すると、非推奨の警告が生成されるようになりました。
 上記の文字セットの代わりにutf8mb4を使用する必要があります。

■ イベントスケジューラ関連

● 以前の利便性として、super_read_onlyシステム変数が無効になっている場合、サーバーは必要に応じてイベントスケジューラを自動的に再起動しました。現在、これと同じ利便性が、read_onlyシステム変数が無効になっている場合、独立して適用されます。この更新の前は、read_onlyを無効にすると、必要に応じてsuper_read_onlyも無効にできましたが、コードが分離されていたため、イベントスケジューラは再起動されませんでした。(バグ #33539082)

■ 全文検索関連

● 実装されているように、MATCH()は引数の関数としてではなく、ベーステーブルの基になるスキャンの現在の行の行IDの関数として機能するため、この関数の引数としてロールアップ列を使用するクエリは、パフォーマンスが低下する傾向があり、信頼性の低い結果が得られました。この場合、MATCH()でのロールアップ列の使用は、次の条件が当てはまる場合は常に許可されなくなりました。
  ・MATCH()は、SELECTリスト、GROUP BY句、HAVING句、またはORDER BY句に見られます。
  ・クエリは、GROUP BY ... WITH ROLLUPを使用します。
  ・グループ化列は、MATCH()の引数として使用されます。
 このようなクエリは、ER_FULLTEXT_WITH_ROLLUPで拒否されるようになりました。(WHERE句でのロールアップ列を使用したMATCH()の使用は、この変更の影響を受けず、引き続き許可されます。)
 (バグ #32565923、バグ #32996762)

■ SQL関数と演算子関連

● 重要な変更:プリペアドステートメントを使用する場合、計算にYEAR、MONTH、またはDAY部分のみの組み合わせ(つまり、時間部分なし)が含まれる場合でも、DATE_ADD()関数とDATE_SUB()関数はDATETIME値を返しました。
 MySQL 8.0.22でプリペアドステートメントの単一準備を実装する前は、このような場合にTIME値が返されていました。これが行われる前は、引数として使用される値とそのタイプを使用して、DATE_ADD()、DATE_SUB()、ADDTIME()などの解決時の特定の時間関数の結果タイプを決定していました。その後は、ユーザー変数参照と動的パラメータは、1回の実行の間のみ一定であると見なされ、戻りタイプを別の方法で、この場合は関数タイプから、決定する必要があります。例えば、DATETIMEは全ての時間値に対応し、暗黙的な再準備を回避できるため、最初の引数が動的パラメータであった場合、DATE_ADD()のデフォルトの解決済みタイプはDATETIMEであると見なされました。
 今説明した変更はリグレッションを表しています。この問題は、より正確に解決されたデータタイプを導出し、それがパラメータの実際の値と一致しない場合にのみ再準備を実行することで、より適切に解決されます。(このような機能は、MySQLサーバーで数値パラメータ用にすでに使用されていました。)このソリューションは、この修正によって実装されます。
 時間値が予想される場合に、文字列と数値を解析するようになりました。有効な時間値が見つかると、その値が変換されます。この修正により、時間関数の解決されるデータタイプの決定も改善されます。
 この修正により、DATE_ADD()関数およびDATE_SUB()関数(およびそれらの同義語関数ADDDATE()およびSUBDATE())は、次のように型を解決します。
  ・最初の引数が動的パラメータであり、2番目の引数がYEAR、MONTH、またはDAY値の
   組み合わせのみを含むintervalである場合、その解決されるタイプはDATEです。
   それ以外の場合、そのタイプはDATETIMEです。
  ・最初の引数がDATETIMEとして解決される場合、関数の解決されるタイプもDATETIMEです。
  ・最初の引数がDATEの場合、interval引数がHOUR、MINUTE、またはSECONDを使用している
   場合を除き、関数の解決されるタイプもDATEです。この場合、それはDATETIMEです。
  ・最初の引数がTIME値の場合、interval引数がYEAR、MONTH、またはDAYのいずれかを
   使用している場合を除き、解決されるタイプもTIMEです。この場合、関数の
   解決されるタイプはDATETIMEです。
 上記の条件のいずれも満たされない場合、関数はVARCHARとして解決されます(MySQL 8.0.21以前の場合と同様)。
 ADDTIME()関数およびSUBTIME()関数は、次のようにタイプを解決するようになりました。
  ・最初の引数が動的パラメータの場合、解決されるタイプはDATETIMEではなくTIMEです。
  ・それ以外の場合、関数の解決されるタイプは、最初の引数の解決されるタイプから派生します。
 さらに、DATE_ADD()およびDATE_SUB()では、最初の引数の解決されるタイプがDATEで、DATETIME値が指定されている場合、関数が解決されるタイプ DATETIMEを持つようにステートメントが再準備されます。TIME値が指定される場合、動作は変わりません。
 ADDTIME()およびSUBTIME()では、強制的な再準備はありません。(バグ #103781、バグ #32915973、バグ #33477883、バグ #33539844)
● 以前は、ロード可能な関数とストアド関数は同じ名前空間を共有し、同じ名前を持つことはできませんでした。その後の実装変更により、同じ名前空間を共有する理由がなくなり、既存のロード可能な関数と同じ名前でストアド関数を作成できるようになりました。ストアド関数を呼び出すためには、スキーマ名で修飾する必要があります。ストアド関数名が既存のロード可能な関数名と衝突した場合、サーバーは警告を生成するようになりました。(バグ #33301931)
● MBRContains()関数を使用するクエリでは、使用可能な全ての空間インデックスが使用されていませんでした。(バグ #32975221)
 参照:この問題は、バグ #29770705のリグレッションです。
● FORMAT()関数は、es_ESまたはes_MXロケールのいずれかが指定されている場合、千単位の区切り文字を表示せず、区切り文字間のグループ化を行わずに、フォーマットされた数値を返しました。(バグ #31374305)
● group_concat_max_lenの値を大きくすると、GROUP_CONCAT()関数の結果の長さが正しくなくなりました。group_concat_max_lenの値が小さい場合、結果は正しいものでした。この問題は、算術オーバーフローが原因で発生しました。
 (バグ #105380、バグ #33521497)

■ オプティマイザ関連

● クエリの場合、範囲スキャンを最初に選択でき、オプティマイザは順序付けをスキップするために同じ範囲スキャンを使用できると判断します。場合によっては、要求された順序がインデックスの順序と同じでない場合、逆インデックススキャンが必要になります。要求された順序が範囲スキャンでまだ使用されていないキーパーツにある場合、範囲スキャンで使用されているキーパーツの数を更新して変更を反映します。この問題は、キーパーツ情報も更新されておらず、使用されているキーパーツの数に基づいてキーパーツ情報にアクセスする必要がある場合に発生しました。
 また、逆スキャンが拡張キーパーツを使用する場合に注意し、それに応じて評価用の正しいフラグを設定します。(バグ #33615893)
 参照:この問題は、バグ #33037007のリグレッションです。
● オプティマイザトレースとEXPLAIN FORMAT=TREE出力の両方で、日付範囲はバイナリとして出力されました。現在は、このような場合、時間値を引用符で囲まれた文字列として出力します。(バグ #33335079)
● 条件がプッシュダウンされると、サブクエリのSELECTリストにあるユーザー変数への割り当てを評価した結果が影響を受けることがありました。この理由から、ユーザー変数に割り当てられたステートメントの条件プッシュダウンを避けるようになりました。
 (バグ #104918、バグ #33341080)
● 結合バッファが特定の任意のサイズに設定されている場合、ハッシュ結合用に作成されたチャンクファイルの数が少なすぎました。つまり、各ファイルには結合バッファに収まるよりも多くの行が含まれているため、プローブチャンクが複数回読み取られる必要がありました。これは、必要なチャンクファイルの数を計算する時に整数除算を使用したことが原因でした。代わりに浮動小数点除算を使用することによりこれを修正します。
 (バグ #104186、バグ #33073354)
● BITタイプで集約を使用するクエリは、使用されるインデックスまたは結合タイプに応じて異なる結果を返す可能性があります。これは、このような集約を使用するDMLステートメントが整数タイプを使用してBIT値をキャッシュし、後でルックアップして出力用の文字列形式に変換するためです。現在の問題は、このルックアップがBIT値を整数として扱い、文字列値が正しくないために発生しました。
 これは、BIT値を文字列形式に正しく変換できる、キャッシュされたBIT値の新しい内部クラスを追加することで修正されています。
 (バグ #100859、バグ #31894023)
● HAVING句内にサブクエリを持つ外部DISTINCTクエリを含むDMLステートメントの場合、内部サブクエリは外部DISTINCTクエリの列の列参照を使用しようとしますが、これは、サブクエリがHAVINGの外部で使用されている場合、または外部のSELECTがグループ化を使用していない場合にのみ許可されます。現在の問題は、これらの条件のいずれも満たされていない場合でも、このようなクエリの実行が許可されていたために発生しました。
 これを修正するために、この種の無効な列参照を検出し、検出された場合はエラーが返されるように、列参照チェックが拡張されます。
 (バグ #97742、バグ #30617496)

■ パッケージ関連

● MySQLのダウンロード可能なパッケージの署名に使用されるGnuPGビルドキーが更新されました。以前のGnuPGビルドキーは2022-02-16に期限切れになるように設定されています。
 GnuPGキーの更新により、repo.mysql.comを使用するように設定されたシステムは、aptまたはyumを使用してMySQL 5.7.37以降またはMySQL 8.0.28以降にアップグレードする時に署名検証エラーを報告する場合があります。この問題を解決するためには、次のいずれかの方法を使用してください。
  a. https://dev.mysql.com/downloads/からMySQL APTまたは
   YUMリポジトリセットアップパッケージを手動で再インストールします。
  b. MySQL GnuPG公開鍵をダウンロードし、それをシステムGPGキーリングに追加します。
 (バグ #33587308)

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

● 新しいステートメントメトリック CPU_TIMEが利用可能になり、クエリに費やされたCPU時間を測定できるようになりました。
 これをサポートするために、次の変更が行われました。
  ・タイマー THREAD_CPUがパフォーマンススキーマ PERFORMANCE_TIMERSテーブルに
   追加されました。
  ・コンシューマー events_statements_cpuがパフォーマンススキーマ setup_consumersテーブルに
   追加されました。
   events_statements_cpuはデフォルトで無効になっています。
  ・コンシューマー events_statements_cpuを有効または無効にするための
   パフォーマンススキーマコマンドオプション、
   performance-schema-consumer-events-statements-cpu。
    ◆ CPU_TIME列が次のパフォーマンススキーマテーブルに追加されました。
      ・events_statements_current
      ・events_statements_history
      ・events_statements_history_long
     CPU_TIMEは、現在のスレッドでCPUに費やされた時間であり、ピコ秒で表されます。
    ◆ SUM_CPU_TIME列が次のパフォーマンススキーマテーブルに追加されました。
      ・events_statements_summary_by_thread_by_event_name
      ・events_statements_summary_by_account_by_event_name
      ・events_statements_summary_by_user_by_event_name
      ・events_statements_summary_by_host_by_event_name
      ・events_statements_summary_global_by_event_name
      ・events_statements_summary_by_digest
      ・events_statements_summary_by_program
      ・prepared_statements_instances
     SUM_CPU_TIMEは、対応する集約で現在のスレッドに費やされたCPU時間であり、
     ピコ秒で表されます。
    ◆ CPU_LATENCY列が次のsysスキーマテーブルに追加されました。
      ・statement_analysis
      ・user_summary_by_statement_type
      ・user_summary_by_statement_latency
      ・host_summary_by_statement_type
      ・host_summary_by_statement_latency
      ・processlist
      ・session
     CPUレイテンシは、現在のスレッドで費やされたCPU時間であり、
     人間が読める形式で表されます。
    ◆ CPU_LATENCY列が次のsysスキーマ x$テーブルに追加されました。
      ・x$statement_analysis
      ・x$user_summary_by_statement_type
      ・x$host_summary_by_statement_type
      ・x$processlist
      ・x$session
      ・x$user_summary_by_statement_latency
      ・x$host_summary_by_statement_latency
     CPUレイテンシは、現在のスレッドで費やされたCPU時間であり、ピコ秒で表されます。
 (バグ #33449453)

■ 追加・変更された機能

● 重要な変更:特定のSELECTに表示できる個別のウィンドウの数は127に制限されました。個別のウィンドウの数は、名前付きウィンドウと、ウィンドウ関数のOVER句の一部として指定されろ暗黙のウィンドウの合計です。
 多数のウィンドウを使用するためには、thread_stackサーバーシステム変数の値を増やす必要がある場合があります。(バグ #33279604)
● InnoDB:InnoDBは、ALGORITHM=INSTANTを使用するALTER TABLE ... RENAME COLUMN操作をサポートするようになりました。
 ALGORITHM=INSTANTをサポートする操作は、データディクショナリのメタデータのみを変更します。操作の準備段階と実行段階では、テーブルに対して排他的なメタデータロックは取得されず、テーブルデータは影響を受けないため、操作は瞬時に行われます。明示的に指定されていない場合、ALGORITHM=INSTANTは、それをサポートするDDL操作によってデフォルトで使用されます。
● 理論的には、MySQL Enterprise Auditを使用する十分な権限を持つユーザーが、自分や他の管理者がシステムにアクセスできないようにする“abort”アイテムを監査ログフィルターに誤って作成する可能性があります。MySQL 8.0.28以降、AUDIT_ABORT_EXEMPT権限を使用すると、ユーザーアカウントのクエリは“abort”アイテムによってブロックされた場合でも常に実行できるようになりました。したがって、この権限を持つアカウントは、監査の設定ミスの後にシステムへのアクセスを回復するために使用できます。クエリは引き続き監査ログに記録されますが、拒否されるのではなく、権限のために許可されます。
 MySQL 8.0.28以降で作成されたSYSTEM_USER権限を持つアカウントには、作成時にAUDIT_ABORT_EXEMPT権限が自動的に割り当てられます。AUDIT_ABORT_EXEMPT権限は、MySQL 8.0.28以降でアップグレード手順を実行すると、SYSTEM_USER権限を持つ既存のアカウントにその権限が割り当てられていない場合、既存のアカウントにも割り当てられます。
● TLSv1およびTLSv1.1接続プロトコルのサポートは、MySQL 8.0.28で削除されました。それらのプロトコルは、MySQL 8.0.26から非推奨でした。より安全なTLSv1.2およびTLSv1.3プロトコルを使用して接続を確立してください。TLSv1.3では、MySQLサーバーソフトウェアとクライアントアプリケーションの両方がOpenSSL 1.1.1以降と共にコンパイルされる必要があります。
 MySQL 8.0.28以降、MySQLサーバーへの接続にTLSプロトコルを指定するための--tls-versionオプションをサポートする、MySQL Shellを含むクライアントプログラムは、TLSv1またはTLSv1.1に設定されたプロトコルでTLS/SSL接続を確立できません。クライアントがこれらのプロトコルを使用して接続しようとすると、TCP接続の場合、接続は失敗し、エラーがクライアントに返されます。ソケット接続の場合、-ssl-modeがREQUIREDに設定されていると、接続は失敗します。それ以外の場合、接続は確立されますが、TLS/SSLは無効になります。
 サーバー側では、次の設定がMySQL 8.0.28から変更されています。
  ・サーバーのtls_versionおよびadmin_tls_versionシステム変数のデフォルト値には、
   TLSv1およびTLSv1.1が含まれなくなりました。
  ・グループレプリケーションシステム変数 group_replication_recovery_tls_version
   のデフォルト値には、TLSv1およびTLSv1.1が含まれなくなりました。
  ・非同期レプリケーションの場合、レプリカは、ソースサーバーへの接続のプロトコルを
   TLSv1またはTLSv1.1に設定できません(CHANGE REPLICATION SOURCE TOステートメントの
   SOURCE_TLS_VERSIONオプション)。
● tmp_table_size変数が、TempTableストレージエンジンによって作成される個々のメモリ内の内部一時テーブルの最大サイズを定義するようになりました。適切なサイズ制限により、個々のクエリがグローバルなTempTableリソースを過度に消費するのを防ぎます。
● InnoDBが一度に開くことができるファイルの数を定義する innodb_open_files変数は、SELECT innodb_set_open_files_limit(N)ステートメントを使用して実行時に設定できるようになりました。ステートメントは、新しい制限を設定するストアドプロシージャを実行します。
 非LRU管理ファイルがinnodb_open_files制限全体を消費するのを防ぐために、現在は、非LRU管理ファイルはinnodb_open_files制限の90%に制限されており、LRU管理ファイル用にinnodb_open_files制限の10%が予約されています。
 innodb_open_files制限には、以前は制限にカウントされなかった一時テーブルスペースファイルが含まれるようになりました。
● 関数FROM_UNIXTIME()、UNIX_TIMESTAMP()、およびCONVERT_TZ()は、それらをサポートする、64ビットバージョンのLinux、MacOS、およびWindowsを含むプラットフォームで64ビット値を処理するようになりました。
 互換性のあるプラットフォームでは、FROM_UNIXTIME()は、'3001-01-18 23:59:59.999999' UTC(最大6桁のオプションの小数部を含む)に対応する32536771199.999999秒の最大引数を受け入れるようになりました。引数がこれより大きい場合、関数はNULLを返します。
 互換性のあるプラットフォームでは、UNIX_TIMESTAMP()は、Unixエポックからの32536771199.999999秒に対応する、最大値 '3001-01-18 23:59:59.999999' UTCを受け入れるようになりました。引数がこれより大きい場合、関数は0を返します。
 さらに、互換性のあるプラットフォームでは、CONVERT_TZ()は、最大 '3001-01-18 23:59:59.999999' UTCまでの2038年以降のタイムゾーン変換を実行するようになりました。datetime引数がこの値を超える場合、引数は変更されずに返されます。この“no-op”の動作は、'2038-01-19 03:14:07.999999' UTCを超える値を使用した以前と同じ動作です。
 32ビットプラットフォームでのこれら3つの関数の動作は変更されていません。
 TIMESTAMPタイプの動作も、この変更による影響を受けません。プラットフォームに関係なく、その最大許容値は'2038-01-19 03:14:07.999999' UTCのままです。これ以降の日付については、代わりにMySQL DATETIMEタイプを使用してください。
● このリリースでは、グローバルおよびユーザーごとのメモリ割り当ての監視と制限が導入されています。global_connection_memory_tracking = 1を設定して有効にする必要がある、Global_connection_memoryステータス変数の値を確認することにより、全てのユーザー接続によって消費される合計メモリを監視できるようになりました。
 この合計には、システムプロセスまたはMySQL rootユーザーが使用するメモリは含まれていません。また、InnoDBバッファプールによって使用されるメモリも考慮されません。
 connection_memory_chunk_sizeを調整することにより、ステータス変数が更新される頻度を間接的に制御できます。Global_connection_memoryは、合計メモリ使用量がこの量を超えて変化した場合にのみ更新されます。
 connection_memory_limitを設定することにより、ユーザー接続ごとのリソース消費の制限を指定できます。メモリ使用量がこの量を超えるユーザーは、追加のクエリを発行できません。global_connection_memory_limitを設定することにより、グローバルメモリ制限を課すこともできます。Global_connection_memoryがグローバル制限を超えると、通常のユーザーはメモリ使用量を必要とする新しいクエリを発行できなくなります。MySQL rootなどのシステムユーザーは、これらの制限に拘束されません。

■ 主なバグ修正

● InnoDB:インデックス作成操作中に計算された最小I/OバッファサイズがI/Oブロックサイズと一致しなかったため、レコードがバッファ境界を超えることができました。(バグ #33570629)
● InnoDB:デバッグビルドでセマフォデッドロックチェッカーによって使用されるsync_array_detect_deadlockアルゴリズムはコードと時間の複雑さの点で単純化され、アルゴリズムの実装はリリースビルドで使用するために導入されました。(バグ #33538505)
● InnoDB:InnoDBソースのut::make_uniqueライブラリ関数で、割り当てられるフィールドのタイプを指定できるようになりました。(バグ #33538461)
● InnoDB:REDOログバッファのメモリ割り当てを追跡するためのパフォーマンススキーマインストゥルメンテーションが追加されました。(バグ #33527660)
● InnoDB:セマフォ待機が長い場合にエラーログに出力される警告は、ラッチの所有者に関する情報を提供しませんでした。(バグ #33509386)
● InnoDB:グローバルロックシステムラッチによって保護されているクリティカルセクションでスレッドが費やす時間を短縮するために、ラッチの解放と再取得のメカニズムが導入されました。(バグ #33502610、バグ #33563523)
● InnoDB:Windowsでのホールパンチ操作がエラーを引き起こしました。この操作は、オーバーラップ(非同期)操作として実行され、イベントオブジェクトへのハンドルを含むOVERLAPPED構造を必要とします。OVERLAPPED構造は提供されませんでした。(バグ #33496778)
● InnoDB:InnoDBソースのut_time()インフラストラクチャは、タイプチェックされた標準ライブラリ実装に置き換えられました。(バグ #33460092)
● InnoDB:復元操作後、多数のTrying to access missing tablespaceというエラーがエラーログに出力されました。(バグ #33437625)
● InnoDB:パフォーマンススキーマ対応のut::make_uniqueおよびut::make_sharedメモリ管理ライブラリ関数がInnoDBソースに追加されました。同様の関数(ut::make_unique_alignedおよびut::make_shared_aligned)が、拡張された配置を持つタイプに追加されました。(バグ #33420694)
● InnoDB:InnoDBソースのbuf_validate()関数が最適化され、デバッグビルドのパフォーマンスが向上しました。
 (バグ #33417058、バグ #104967)
● InnoDB:NUMA対応システムで、バッファプールに割り当てられたメモリチャンクのページサイズが特定のシナリオでシステムページサイズと一致しなかったため、次のエラーが発生しました:Failed to set NUMA memory policy of buffer pool page frames to MPOL_INTERLEAVE。(バグ #33406701)
 参照:この問題は、バグ #32714144のリグレッションです。
● InnoDB:InnoDBソースのmem_heapを持つstd::unique_ptrの2つのインスタンスは、関数へのポインターの代わりにステートレス関数オブジェクトを使用するScoped_heap()ラッパーを使用するようになりました。(バグ #33405520)
● InnoDB:ビルド済み構造体のm_end_rangeフラグは、プリフェッチキャッシュにデータを入力している間に範囲の終わりを超えた時にtrueに設定されますが、プリフェッチキャッシュがリセット(初期化)された時にfalseに設定されませんでした。その結果、範囲の終わりを超えずにハンドラーが再利用される場合、次にプリフェッチキャッシュが使用される時にm_end_rangeフラグが誤って設定される可能性があります。(バグ #33384537)
● InnoDB:テーブルのインポート操作中にテーブルのテーブルスペースを破棄した後、新しいテーブルIDがテーブルに割り当てられた時に、データディクショナリの列メタデータが更新されませんでした。(バグ #33319149)
● InnoDB:innodb_interpreterデバッグ専用システム変数をNULLに設定すると、エラーが発生しました。(バグ #33316661)
● InnoDB:フルテキストインデックス作成ファイルの管理が改善されました。(バグ #33270893)
● InnoDB:集約に使用される一時テーブルに新しい行を挿入するUPDATE操作により、一時テーブルがディスクに移動され、UPDATE操作が新しいディスク上の一時テーブルで再試行されました。一時テーブルがディスクに移動される前に準備されたレコードデータのBLOBポインタは古くなり、エラーが発生しました。(バグ #33242407)
● InnoDB:メモリ割り当ては、パフォーマンススキーマと互換性のある新しい標準準拠のカスタムメモリアロケータによって実行されるようになりました。(バグ #33159210)
● InnoDB:発生した同じテーブルの統計を非初期化および初期化しようとするスレッド間の競合状態とアサーションの失敗。(バグ #33135425)
● InnoDB:1以外のinnodb_flush_log_at_trx_commit設定または長時間実行されるトランザクションにより、REDOログのフラッシュの速度に一貫性がなくなる可能性がありました。(バグ #33128461)
● InnoDB:ラージページの割り当ては、これを処理するように設計されたライブラリによって処理されるようになりました。ラージページ割り当てメカニズムを使用できない場合、フォールバックメカニズムが通常の整列されたページを割り当てます。フォールバックは、ラージページのアドレススペースが使い果たされた場合、基盤となるハードウェアまたはオペレーティングシステムアーキテクチャによってラージページサポートが無効にされた場合、または、MySQLのラージページサポートが明示的に無効にされた場合(--large-pages=0)に発生する可能性があります。ラージページの割り当てと割り当て解除のためのut_allocator関数の出現は、新しいライブラリ関数に置き換えられました。(バグ #33119009、バグ #33118309、バグ #33149501、バグ #32135935)
● InnoDB:通常の4Kページ整列割り当ての処理は、パフォーマンススキーマと互換性のある自己完結型ライブラリによって実行されるようになりました。(バグ #33118362)
● InnoDB:適切に配置されたタイプの動的ストレージ管理を担当する新しいInnoDBライブラリに属する関数は、この目的で以前使用されていた関数に置き換わりました。(バグ #33110341)
● InnoDB:適切に配置されたタイプの動的割り当てが、パフォーマンススキーマと互換性のあるライブラリによって処理されるようになりました。(バグ #33110312)
● InnoDB:パージスレッドがパージバッチの最後にLOBページを解放している時に、必要なインデックスデータ構造が解放され、エラーが発生しました。(バグ #32918325)
● InnoDB:動的メモリ管理関数(ut_*関数)のパフォーマンススキーマインストゥルメンテーションロジックの不整合が解決されました。(バグ #32715466)
● InnoDB:InnoDBの動的割り当てルーチンの制限により、構成可能なタイプの配列の動的割り当てが妨げられていました。その制限に対処し、デフォルトの構成可能なタイプ、デフォルト以外の構成可能なタイプ、およびデフォルトとデフォルト以外の構成可能なタイプの両方の割り当てを許可しました。(バグ #32714047)
● InnoDB:READ COMMITTEDまたはREAD UNCOMMITTEDを使用すると、トリガーまたは関数内のテーブルで実行された特定のクエリにより、同じテーブルでの同時トランザクションが妨げられました。取得されたロックは制限が厳しすぎました。(バグ #32636792)
● InnoDB:暗号化および圧縮されたテーブルスペースページ、Windowsのほとんどのページ、およびMicrosoftボリューム管理機能を実装していないWindowsボリュームでは、ホールパンチ機能が期待どおりに機能しませんでした。(バグ #32136255)
● パーティショニング:生成された列式で非決定的な関数を使用してテーブルを作成することはできないはずですが、これは全ての場合に強制されたわけではありませんでした。一連の1つ以上のALTER TABLEステートメントを使用して、1つ以上のそのような生成された列を持つパーティションテーブルに到達することができます。このテーブルに対してSHOW CREATE TABLEを実行することにより取得したCREATE TABLEステートメントを実行しようとすると、MySQLは、パーティション式自体は有効であるにもかかわらず、問題のある列ではなくパーティション式を参照する誤解を招くエラーメッセージでステートメントを拒否しました。
 これは、(内部変数 thd->safe_to_cache_queryで)生成された列に対して定義された安全でない式をチェックした結果が原因でした。これは、パーティション式の解析中にクリアされずに後で再度チェックされたため、パーティション式が問題のある生成された列式を参照していなくてもエラーが発生しました。このような場合、パーティション関数を解析する前に、thd->safe_to_cache_queryをリセットするようになりました。
 生成された列で特定の非決定関数(AES_ENCRYPT()、AES_DECRYPT()、RANDOM_BYTES())の使用を許可する問題は、個別に処理されます。(バグ #29268656)
 参照:バグ #32592320。
● パーティショニング:パーティショニングされたテーブルのプライマリキー以外のインデックスを使用したクエリでは、CPUの負荷が高くなることがありました。(バグ #104576、バグ #33238010)
● レプリケーション:パフォーマンススキーマレプリケーショングループメンバー統計テーブルがチェックされている時に、グループレプリケーションが自動再結合手順中に予期せず停止することがありました。操作の同時実行が正しく処理されるようになりました。(バグ #33609089)
● レプリケーション:グループメンバーが分散リカバリのドナーになるためのグループレプリケーションの選択プロセスには、オペレーティングシステム用に定義された標準のランダムセレクターの使用が含まれます。このランダムなデバイスが利用可能ではなく、例外がスローされた場合、参加メンバーの参加プロセスは停止しました。グループレプリケーションは、この可能性を考慮に入れ、オペレーティングシステム上のセレクターがエラーを返す場合にフォールバックランダムセレクターを使用するようになりました。(バグ #33596124)
● レプリケーション:インスタンスがバックアップ用にロックされている時にPURGE BINARY LOGSステートメントが発行される可能性がありました。これは、サーバーからファイルを削除することにより、バックアップロックのルールに違反していました。LOCK INSTANCE FOR BACKUPステートメントが有効になっている間は、このステートメントを使用できなくなりました。(バグ #33437026)
● レプリケーション:STOP GROUP_REPLICATIONステートメントは、グループメンバーの非同期レプリケーションチャネルを停止しますが、STOP REPLICAが行うように、進行中のトランザクションを暗黙的にコミットしません。これは、グループレプリケーショングループメンバーで、シャットダウン操作中にコミットされた追加のトランザクションにより、メンバーがグループと不整合になり、再参加で問題が発生するためです。操作が完了すると、サーバーは読み取り専用状態のままになります。この状況では、グループレプリケーションの停止中に進行中のトランザクションのコミットが失敗するため、これらを回避するために、現在は、GTIDがgtid_nextシステム変数の値として割り当てられている間は、STOP GROUP_REPLICATIONステートメントを発行できなくなりました。(バグ #33412483)
● レプリケーション:グループレプリケーションの自動再参加手順を使用してグループに再参加していた追放されたグループメンバーは、他のグループメンバーから情報を収集している最中に、互換性チェックが完了する前に、早い段階でその状態をRECOVERINGとして報告しました。状態変更は、再参加するメンバーが実際にグループメンバーとして受け入れられるポイントであるビューのインストール中に、実行されるようになりました。(バグ #33380840)
● レプリケーション:テーブルまたはデータベースの名前が64バイトを超える場合(制限は64文字)、レプリケーションがテーブルマップイベントの読み取り中にエラーで停止しました。そのため、マルチバイト文字を使用すると、この状況が発生する可能性がありました。レプリカは、テーブル名とデータベース名のサイズをチェックしなくなり、より長い名前の送信をサポートするようになりました。(バグ #33305975、バグ #104798)
● レプリケーション:STOP REPLICAコマンドの進行中に、パフォーマンススキーマテーブルreplication_applier_status_by_workerにクエリが実行された場合、ロックの競合が発生する可能性がありました。この問題は解決されました。(バグ #33290947)
● レプリケーション:MySQL 8.0.26から、準同期レプリケーションを実装するプラグインの新しいバージョンが提供され、“master”と“slave”という用語が“source”と“replica”に置き換えられました。この後に、UNINSTALL PLUGINステートメントは、レプリケーションチャネルが今それらを使用している時に、古いバージョンのプラグイン、rpl_semi_sync_masterおよびrpl_semi_sync_slaveをアンインストールすることを誤って許可していました。この問題は修正されました。(バグ #33270401)
● レプリケーション:レプリカサーバーでPAD_CHAR_TO_FULL_LENGTH SQLモードが有効になっていると、レプリケーションメタデータリポジトリテーブルのレプリケーションチャネルの名前に末尾のスペースが追加され、そのデータを使用してチャネルを識別するレプリケーション操作でエラーが発生する可能性がありました。この問題は、MySQL 8.0では文字の列にVARCHARを使用することで修正され、MySQL 5.7ではこれらのテーブルから読み取る時にSQLモードを無効にすることで修正されました。(バグ #33213841)
● レプリケーション:SHOW REPLICASステートメントの発行中にレプリカが接続切断されていた場合、サーバーは削除されたデータにアクセスできました。(バグ #33206343、バグ #104566)
● レプリケーション:グループレプリケーションでは、次のトランザクション用にGTIDを設定するためにSET gtid_nextステートメントがグループメンバーに対して使用されると、別のメンバーで同時に開始するトランザクションに同じGTIDが使用される可能性があります。両方のトランザクションがコミット段階に達すると、全順序の2番目のトランザクションがロールバックされ、状況が解決されます。ただし、グループレプリケーションのトランザクション整合性レベル(group_replication_consistencyシステム変数)がBEFOREまたはBEFORE_AND_AFTERに設定されている場合、メンバーは、1つがgtid_ownedセットのGTIDの所有権を保持し、もう1つがトランザクションをコミットする前に所有権が解放されるのを待機することで、デッドロックに達する可能性がありました。待機関数は、コミットされたトランザクションのGTIDのみを考慮し、所有されているがコミットされていないGTIDは考慮しないようになりました。ただし、セッションが同時にコミットされるGTIDを所有している場合を除きます。この場合、実行中のセッションはエラーになります。(バグ #33051454、バグ #104096)
● レプリケーション:システム変数 replica_preserve_commit_order=1が設定されたレプリカサーバーが長期間にわたって集中的な負荷の下で使用された場合、インスタンスはコミットオーダーシーケンスチケットを使い果たす可能性がありました。最大値を超えた後の誤った動作により、アプライヤーがハングし、アプライヤーワーカースレッドがコミットオーダーキューで無期限に待機しました。コミットオーダーシーケンスチケットジェネレーターが正しく最低値に戻るようになりました。(バグ #32891221、バグ #103636)
● レプリケーション:グループレプリケーションのグループ通信エンジン(XCom、Paxosバリアント)は、ネットワークの問題などにより、既存のグループメンバーが参加するメンバーと通信するのが困難な状況で、より多くの情報をログに記録するようになりました。これにより、グループは参加するメンバーの前身を思い出し、再度参加を試みることを許可しない可能性があります。(バグ #32873315)
● レプリケーション:グループレプリケーションのグループ通信システム(GCS)は、追放されたメンバーの記録を、グループへの参加に成功したメンバーと、グループへの参加に成功しなかったメンバーとで区別するようになりました。(バグ #32630484)
● レプリケーション:グループレプリケーションが開始または停止されている時に、パフォーマンススキーマのグループレプリケーショングループメンバー統計にクエリが実行された場合、競合状態が発生しました。(バグ #32392468)
● レプリケーション:レプリケーションソースサーバーが4GBオフセットを超えるバイナリログファイルの位置を含むハートビートイベントを送信した場合、バイナリログファイルのサイズが大きいために、レプリケーションレシーバースレッドはエラーで停止しました。この状況で使用するために、より大きな値を正しく処理する新しいハートビートイベント(Heartbeat_log_event_v2、ログイベントタイプ41)が追加されました。(バグ #29913991)
● Microsoft Windows:Windowsで、MySQLサーバー(商用)およびMySQL NDB Cluster(商用およびコミュニティ)用に不足しているデバッグおよびテストスイートのバイナリを追加しました。(バグ #32713189)
● JSON:JSON_TABLE()に渡される最初の引数が単一のJSON値ではなく行である場合、行式を評価しようとした時にアサーションが発生しました。最初の引数が行の場合、関数の解決中にエラーを発生させて、行式自体が評価されないようにすることによって、これを修正します。(バグ #33414235)
● 生成された列の式でのLPAD()またはRPAD()の使用は、親テーブルのインデックスの破損につながりました。(バグ #33661337)
 参照:バグ #32668730、バグ #33238711。
● 警告が発行されたいくつかのケースで、一時テーブルを使用した集約の結果から行が欠落していました。(バグ #33603911)
● openSUSE 15の場合、mysql.specにlibtirpc rpcgenビルド要件を追加しました。現在は、TI-RPCを使用するようになりました。(バグ #33582982)
● 複数のテーブルに作用するUPDATEステートメントは、実行される度にリストに要素を追加することがあります。要素はこのリストから削除されることはなく、これにより、ステートメントを実行する度にメモリフットプリントが増加しました。実行後に要素リストをクリアすることでこれを修正します。(バグ #33574408)
● パフォーマンススキーマのprocesslistテーブルのHOST列のサイズがVARCHAR(255)からVARCHAR(261)に増やされました。(バグ #33570218)
● OpenSSLエラーによるキーリングの移行エラーにより、アサーションが発生しました。SSLエラー状態は、スレッドのOpenSSLエラーキューからフラッシュされませんでした。(バグ #33546207)
● プロセスリスト関数呼び出しが失敗を引き起こしました。(バグ #33511690)
● 商用のDebianサーバーパッケージには、2つのテストプラグイン(component_test_page_track_component.soとcomponent_test_global_priv_registration.so)が含まれていました。それらは、別のオプションのテストパッケージに移動されました。(バグ #33504443)
● Fedoraについて、リリースパッケージのバージョン番号を1から10に増やしました。これは、同じバージョンのネイティブFedora dnf/yumパッケージに関する潜在的なインストール関連の問題を排除するのに役立ちます。(バグ #33504443)
● Debianベースのパッケージの互換性レベルを、以前のレベルである9が非推奨になったため、11に上げました。互換性レベル 10+の要件を満たすために、dh_systemd_enable + dh_systemd_startの呼び出しをdh_installsystemdに置き換えました。(バグ #33458752)
● 全文検索クエリを含む削除操作が失敗しました。(バグ #33455243)
● 不適切に処理されたエラーにより、keyring_okvプラグインを使用する時に起動エラーが発生しました。(バグ #33449117)
● Debianについて、デバッグビルドによって必要とされる全ての必要なパッケージをプルするために、mysql-community-server依存関係をmysql-community-server-debugパッケージに追加しました。(バグ #33426737)
● タイプ DECIMALのバーチャル生成列について、常に一部のデータを格納するようになりました。これにより、フィールドバッファを10進値に変換しようとする時の未定義の動作を回避できます。(バグ #33424846)
● MySQLは、基になる派生テーブルからの式にストアドプロシージャによって設定された変数が含まれている場合、条件を派生テーブルにプッシュダウンすることをサポートするようになりました。(バグ #33423394)
● tls_versionおよびadmin_tls_versionの設定は、サーバーの起動時に検証されるようになりました。(バグ #33390209)
● admin_tls_version変数が無効な値を受け入れました。(バグ #33389818)
● 2つ以上の非推奨のシステム変数がSET PERSISTステートメントを使用して永続化された場合、サーバーが再起動されると、非推奨の警告は最初の非推奨のシステム変数に関してのみログに記録されました。(バグ #33388488)
● キーパーツが等しいインデックス範囲スキャンの場合、その範囲は等しいとして表示されるようになりました。例えば、この変更の前の3 <= a <= 3の代わりに、a = 3が表示されるようになりました。(バグ #33351123)
● /var/runの使用がtmpfiles.d設定ファイルでは非推奨であるため、/var/run参照を/runに置き換えました。/var/runから/runへのシンボリックリンクは、現在のセットアップを機能させるために残されています。(バグ #33351110、バグ #33588618)
● 特定の設定のサーバーでSHOW PROCESSLISTを実行するか、INFORMATION_SCHEMA.PROCESSLISTにアクセスすると、エラーが発生しました。(バグ #33341623)
● ICUエラーコード U_FILE_ACCESS_ERRORから新しいMySQLエラーコード ER_REGEXP_MISSING_FILEへのマッピングを追加しました。(バグ #33326003)
● キーリング関数の引数の検証チェックに失敗すると、エラーが発生しました。(バグ #33319782)
● CMakeオプション DWITH_GROUP_REPLICATION=0を使用してMySQLソースディストリビューションでグループレプリケーションプラグインを無効にしても、グループレプリケーションに関連するアプリケーションとテストが無効にならず、正しくビルドされませんでした。(バグ #33308513)
● インデックス範囲スキャンイテレータは、常に期待どおりに検査される行数を増やすとは限りませんでした。(バグ #33305632)
● コマンドラインでcreate_admin_listener_threadシステム変数を有効にすると、特定のエラー状態で起動中にサーバーが終了する可能性がありました。(バグ #33300587)
● SUBSTR()関数は、その引数を評価しようとした時に発生したエラーを常に正しく処理するとは限りませんでした。(バグ #33290160)
● Unicodeバージョン67のInternational Componentsは、\X(graphemeクラスタに一致)の新しい実装を導入しました。これは、現在MySQLに含まれていないロケールデータを必要とします。
 これは、MySQLにバンドルされているバージョンのICUを使用する場合、\Xを使用するクエリがエラー ER_REGEXP_MISSING_RESOURCEを引き起こすことを意味します。システムが提供するICUを使用する場合、ER_WARN_REGEXP_USING_DEFAULTをメモとして報告します。(バグ #33290090)
● 選択したクエリプランがフルテキストインデックススキャンを使用したBLACKHOLEストレージエンジンに格納されているテーブルに対するフルテキスト検索クエリは、空の結果セットを返す代わりにエラーを引き起こしました。(バグ #33250020)
● 行ロックに費やされた時間、および複数のテーブルをロックするために費やされた時間が欠落しているため、パフォーマンススキーマによって返されるLOCK_TIMEは過小評価されていました。このリリースの時点で、LOCK_TIMEは以下を考慮しています。
  ・SQLテーブルで待機した時間全て
  ・DATAロックの待機時間全て
 LOCK_TIMEは、スローログとパフォーマンススキーマで一貫して報告されるようになりました。(バグ #33236909)
● mysqlクライアントプロンプトの新しいオプション \Tは、現在のセッションがトランザクションブロック内にある場合、アスタリスク(*)を出力します。このオプションは、--promptコマンドラインオプションとともに、MySQLオプションファイルで、または、MYSQL_PS1環境変数とともに使用できます。(バグ #33214862、バグ #104598)
● RANGE INTERVAL式の定数サブクエリは、常に正しく処理されるとは限りませんでした。(バグ #33197418)
● NULLと評価された10進式は、常に正しく処理されるとは限りませんでした。(バグ #33169048)
● グローバルのSELECT権限を持つMySQLロールを付与されたユーザーアカウントは、mysqlデータベースへのアクセスを拒否されました。ロールが付与された時に、ユーザーアカウントのグローバル権限がチェックされませんでした。(バグ #33159353、バグ #104423)
● Item_refをSELECTエイリアスに設定すると、そのキャッシュされたプロパティがコピーされます(ROLLUP式の一部であるかどうかを含む)。ただし、これらはまだ正しく計算されていない可能性があるため、最初に計算を実行する必要があります。そうしないと、値が間違っている可能性があります。値が間違っていると、特定の式が実体化されるべきではない時に中間ステップで実体化される可能性がありました(なぜなら、それらは計算の準備ができていないROLLUP式を含んでいますが、間違った値を持つことは現時点では不明であるためです)。この問題は、アイテムがロールアップアイテムとして指定された時に、キャッシュされた値を強制的に再計算することで修正されます。(バグ #33149402、バグ #104394)
● テーブルをMySQL 5.7からMySQL 8.0にアップグレードしている時に無効なコメント文字列が検出されたため、十分なコンテキスト情報が提供されなかったというエラーでアップグレードが失敗しました。(バグ #33148961)
● 場合によっては、SERIALタイプの生成された列を作成することが可能でしたが、これは許可されていません。
 (バグ #33141966)
● トランザクションを暗黙的または明示的にコミットするステートメントは、トリガーまたはストアドファンクション内では許可されていません。この場合、CREATE TRIGGERとCREATE FUNCTIONの両方がエラー(ER_COMMIT_NOT_ALLOWED_IN_SF_OR_TRG)を報告する必要がありますが、DROP TABLESPACEを正しく処理しませんでした。(バグ #33141958)
● SHOW TABLE STATUS操作は、非常に大きなAVG_ROW_LENGTH値で定義されたテーブルで実行されると、アサーションエラーを発生させました。 (バグ#33114368)
● スキャンから読み取られる可能性のある最大行数を計算すると、中間結果はdoubleになり、それは64ビットの符号なしの整数の最大許容値よりも大きくなる可能性がありました。これにより、中間のdouble値を整数に変換する時に未定義の動作がトリガーされ、場合によってはアサートの失敗につながる可能性がありました。
 結果を[1, UINT64_MAX]の範囲でクランプすることにより、これを修正します。(バグ #33066458)
● UNIONとLIMIT 0の両方を使用するクエリは、デバッグビルドでアサートエラーをトリガーしました。(バグ #33066455)
 参照:この問題は、バグ #32302724のリグレッションです。
● ALTER EVENT ... RENAME TOを使用してイベントの名前を変更しても、元のイベントのパフォーマンススキーマインストゥルメンテーションは削除されませんでした。(バグ #33059358)
● スレッドプールプラグインを使用すると、デバッグビルドでSSLハンドシェイクアサーションが発生しました。(バグ #33012398)
● GROUP BY WITH ROLLUPまたは1つ以上のウィンドウ関数のいずれかを使用するプリペアドステートメントの中には、1回だけ正常に実行できるものがありました。(バグ #33007266)
● INSERT INTO view VALUE(tuple) AS row_alias(id_list)の形式のステートメントでエラーが発生しました。このようなステートメントを実行すると、サーバーは、VALUESエイリアスとして作成された派生テーブルを準備するために、内部関数 Sql_cmd_insert_base::prepare_values_table()を呼び出します。この関数は、基になるテーブルのフィールドを指すItem_fieldオブジェクトをSql_cmd_insert_base.values_field_listに入力します。テーブルではなくビューに挿入する場合、ビュー列を参照するItem_view_refから基になるテーブルの対応する列を表すItem_fieldにマップするために必要とされる、予期されるreal_item()変換は実行されませんでした。(バグ #32858783)
● 一部の複数ネストされたサブセレクトは正しく処理されず、サーバーの計画外のシャットダウンにつながる可能性がありました。(バグ #32547812)
● SHOW PROCESSLIST操作中のセッションスレッドオブジェクトの検査と、スレッドのセキュリティコンテキストへの同時変更により、競合状態が発生しました。(バグ #32320541、バグ #102052)
● UNIONの結果に対して実行される操作がない場合、一時テーブルのプレースホルダーはクエリブロックにまだ存在しますが、行は一時テーブルに格納せずにストリーミングされます。このテーブルはインスタンス化されていないため、アクセスコストを計算し、範囲ベースのアクセスを最適化する際に、テーブルから行を読み取るコストの見積もりをチェックすると、予測できない結果が生じました。
 インスタンス化されていない一時テーブルの場合、このような行の見積もりの取得をスキップすることで、これを修正します。(バグ #32255904)
● 一般的なテーブル式を使用するマルチテーブルDELETEステートメントは、常に正しく処理されるとは限りませんでした。(バグ #32238558)
 参照:この問題は、バグ #98330、バグ #30796015のリグレッションです。
● 潜在的なメモリリークを回避するために、SSL関連のコードが改訂されました。(バグ #31933295)
● 場合によっては、複数テーブルのUPDATEステートメントが同時アクセスをブロックする可能性がありました。(バグ #31731752)
● 複雑な設定に内部スロットを使用するキーリングシステム変数は、DEFAULTの設定を受け入れなくなりました。(バグ #30879700)
● mysql.tables_privおよびmyql.columns_priv GrantテーブルのTimestamp列は、GRANT操作およびREVOKE操作のタイムスタンプ値がゼロ("0000-00-00 00:00:00")に設定され、Grantテーブルの論理的な復元を回避するようになりました。MySQL 8.0.28以降、有効な開始時刻の値がTimestamp列に書き込まれます。
 タイムスタンプ値がゼロの既存のGrantテーブルレコードがあり、Grantテーブルの論理的な復元が回避されている場合、回避策は、Grantテーブルまたはダンプファイルのレコードを更新し、ゼロのタイムスタンプ値をCURRENT_TIMESTAMPに置き換えることです。
 (バグ #30863899、バグ #98495)
● MySQL 5.7および8.0でのmysqldumpを使用したテーブルごとのダンプの生成は、MySQL 5.6に比べて実行時間が長くなります。これは、mysqldumpによってログファイルグループに関する情報が問い合わせされるinformation_schema.filesテーブルに、MySQL 5.7のNDBデータファイルとともにInnoDBデータファイルに関する情報も含まれているためです。MySQL 8.0では、適切なデータファイルのみを選択するようにクエリを書き直すことで、この問題が修正されています。MySQL 5.7では、インフォメーションスキーマテーブルにインデックスがないため、全表スキャンが引き続き必要とされます。(バグ #29210990、バグ #93875)
● キーリングのメモリ管理が改善されました。(バグ #25042167)
● テーブル内のFORCE INDEXヒントの存在を保存および復元する時に、FORCE INDEX FOR GROUP BYの値が正しく設定されていない可能性がありました。(バグ #105694、バグ #33604416)
● sql_buffer_resultシステム変数が有効になっているクエリが1行だけを返し、その結果をテーブルに挿入しようとした場合、一時テーブルからの出力の設定中にエラーが発生して、データ例外が発生する可能性がありました。(バグ #105351、バグ #33515752)
 参照:この問題は、バグ #33152269のリグレッションです。
● ウィンドウの入力結果セットの最後にあるWindowIterator::Read()で、アクティブなスライスのリセットが実行されませんでした。これにより、ORDER BYソート段階ではウィンドウ関数の計算後に値を読み取る必要がありますが、アクティブなスライスの数はまだ1(つまり、入力テーブルから読み取られる項目)に設定されているため、ORDER BYソートに到達した時に誤った値が読み取られました。このためには、アクティブなスライスが最後のウィンドウの出力テーブルのスライスである必要があります。
 これを修正するためには、読み取りの直後にスライスのリセットを出力スライスに移動します。これにより、入力セットの最後に戻って順序付けに進む時に、スライスが既に正しく設定されています。
 (バグ #105045、バグ #33399696)
● コピー先のバッファの最後のバイトがnullバイトであることを確認せずに、内部関数 set_parse_error_message()でstrncpy()が使用されていることが、コード検査により明らかになりました。strncpy()の代わりにsnprintf()を使用してこれを修正します。これにより、結果は切り捨てられた場合でも有効になります。(バグ #104856、バグ #33321787)
● DEFINER句(またはストアドファンクション)で作成されたトリガーをアクティブ化するプリペアドステートメントを実行すると、定義者権限の代わりに呼び出し元権限がテーブルアクセスのチェックに使用されました。これにより、トリガーまたはストアドファンクションによって使用されるテーブルの権限チェックが失敗する可能性がありました。(バグ #104168、バグ #33064461)
● シングルトンヒストグラムが作成されると、その累積度数は、前のバケットの度数を現在のバケットに加えることによって計算されます。アキュムレータに浮動小数点値が使用されたため、これにより、最終累積度数が1.0よりわずかに大きくなることが原因で、累積フロートエラーが発生することがありました。
 この修正により、中間の浮動小数点エラーを回避するために、代わりに整数型で度数が累積されます。
 (バグ #104108、バグ #33045336)
● 複数値のインデックスは、ストアドファンクション内から実行されるクエリには使用されませんでした。(バグ #102359、バグ #32427727)
 参照:バグ #104700、バグ #33268466。
● 次の形式のSQLステートメントでエラーが発生しました。
   INSERT INTO target_table
     SELECT aggregate_expression, non_aggregate_expression
     FROM empty_table;
 これは、クエリプランが一時テーブルからの集約を使用した場合やクエリの1回の実行中にnon_aggregate_expressionが一定であったが実行ごとに異なる可能性がある場合に発生しました。このような式には、例えば、NOW()やUSER()などの関数が含まれる場合があります。これにより、一時テーブルはnon_aggregate_expressionの列を取得しましたが、全ての行の値が同じであるため、これは不要です。さらに、行がない場合、target_tableに挿入する正当な値はありませんでした。これが、実際にエラーを引き起こしたものです。
 non_aggregate_expressionが現在の実行に対してconstである場合、一時テーブル列を使用しないことでこれを修正します。(バグ #102252、バグ #32384355、バグ #33546083)
● 文字列として渡された値を含むプリペアドステートメントを実行すると、MySQLはそれらを整数として解析しようとし、入力値に関係のないエラーを返す可能性がありました。
 最近の変更後、動的パラメータ処理がリファクタリングされ、パラメータの派生データタイプがコンテキストに基づいて決定されるようになりました。例えば、int_col = ?などの比較では、パラメータには、比較対象の(整数)列と同じタイプが指定されています。既存のMySQLアプリケーションとの互換性を維持するために、10進値または浮動小数点値がパラメータとして指定された場合、ステートメントは、実際の値に基づいてパラメータに割り当てられた新しいタイプで自動的に再準備されました。この処理により、数値パラメータの互換性が維持されました。
 ただし、文字列パラメータが指定された場合でも、それは整数(解決されたデータタイプ)として解釈され、この動作は値の実際のタイプを検出した古いバージョンのMySQLと互換性がありませんでした。その結果として、int_col = ?がパラメータ値'1.7'で実行される場合、文字列の整数部分のみが使用され、効果的な比較int_col = 1が作成されます。
 この問題を修正するために、文字列パラメータが指定されると、パラメータが分析されて整数、小数、または浮動小数点値のいずれであるかが判別され、それに応じてパラメータの実際のデータタイプが更新されます。後で、実際のタイプが解決されたタイプと比較され、互換性がない場合は、ステートメントが新しい実際のタイプで再準備されます。したがって、前のステートメントはint_col = 1.7として評価され、比較は10進数を使用して評価されます。(バグ #101806、バグ #32213576、バグ #103364、バグ #32787037)

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

MySQL Editions

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

MySQL Editionsの詳細