MySQL :: MySQL 8.0 リファレンスマニュアル

9.3 English
9.2 English
9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / 一般情報 / MySQL 8.0 の新機能

このページは機械翻訳したものです。

1.3 MySQL 8.0 の新機能

このセクションでは、MySQL 8.0 で追加された機能、非推奨になった機能、および削除された機能について要約しています。コンパニオンセクションには、MySQL 8.0 で追加、非推奨または削除された MySQL サーバーのオプションおよび変数がリストされます。セクション1.4「MySQL 8.0 で追加、非推奨または削除されたサーバーおよびステータスの変数とオプション」を参照してください。

MySQL 8.0 で追加された機能

次の機能が、MySQL 8.0 に追加されました。

データディクショナリ. MySQL には、データベースオブジェクトに関する情報を格納するトランザクションデータディクショナリが組み込まれています。以前の MySQL リリースでは、ディクショナリデータはメタデータファイルおよび非トランザクションテーブルに格納されていました。詳細は、第14章「MySQL データディクショナリ」を参照してください。
アトミックデータ定義ステートメント (アトミック DDL). アトミック DDL ステートメントは、DDL 操作に関連付けられたデータディクショナリ更新、ストレージエンジン操作およびバイナリログ書込みを組み合せて、単一のアトミックトランザクションにします。詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」を参照してください。
アップグレード手順. 以前は、新しいバージョンの MySQL をインストールした後、次回の起動時に MySQL サーバーは自動的にデータディクショナリテーブルをアップグレードしていましたが、その後、DBA が手動で mysql_upgrade を起動して、mysql スキーマ内のシステムテーブルおよび sys スキーマやユーザースキーマなどの他のスキーマ内のオブジェクトをアップグレードする必要がありました。

MySQL 8.0.16 では、サーバーは以前 mysql_upgrade によって処理されていたタスクを実行します。新しい MySQL バージョンのインストール後、サーバーは次回の起動時に必要なすべてのアップグレードタスクを自動的に実行するようになり、DBA が mysql_upgrade を呼び出す必要はなくなりました。また、サーバーはヘルプテーブルの内容を更新します (mysql_upgrade では更新されませんでした)。新しい --upgrade サーバーオプションは、サーバーがデータディクショナリおよびサーバーの自動アップグレード操作を実行する方法を制御します。詳細は、セクション2.11.3「MySQL のアップグレードプロセスの内容」を参照してください。
セキュリティとアカウント管理. セキュリティを向上させ、アカウント管理における DBA の柔軟性を高めるために、次の拡張機能が追加されました:
- mysql システムデータベース内の付与テーブルが InnoDB (トランザクション) テーブルになりました。以前は、これらは MyISAM (非トランザクション) テーブルでした。付与テーブルのストレージエンジン変更により、アカウント管理ステートメントの動作が変わります。以前は、複数のユーザーを指定したアカウント管理ステートメント (CREATE USER や DROP USER など) は、一部のユーザーに対して成功し他のユーザーに対して失敗することがありました。現在は、各ステートメントはトランザクションに対応し、指定されたすべてのユーザーに対して成功するか、エラーが発生した場合はロールバックされて何の影響も与えなくなりました。ステートメントが成功した場合はバイナリログに書き込まれますが、失敗した場合は書き込まれず、ロールバックが発生して変更は行われません。詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」を参照してください。
- 新しい caching_sha2_password 認証プラグインが使用可能です。 sha256_password プラグインと同様に、caching_sha2_password は SHA-256 パスワードハッシングを実装しますが、接続時の待機時間の問題に対処するためにキャッシュを使用します。ほかにも多くのトランスポートプロトコルをサポートしており、RSA キーペアベースのパスワード交換機能のために OpenSSL とのリンクを必要としません。セクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」を参照してください。
  
  caching_sha2_password および sha256_password 認証プラグインは、mysql_native_password プラグインよりもセキュアなパスワード暗号化を提供し、caching_sha2_password は sha256_password よりも優れたパフォーマンスを提供します。 caching_sha2_password のこれらの優れたセキュリティおよびパフォーマンス特性のため、現在は優先認証プラグインであり、mysql_native_password ではなくデフォルトの認証プラグインでもあります。サーバー操作のためのデフォルトのプラグインのこの変更による影響、およびサーバーとクライアントおよびコネクタとの互換性については、優先認証プラグインとしての caching_sha2_password を参照してください。
- MySQL では、権限の名前付きコレクションであるロールがサポートされるようになりました。ロールは作成および削除できます。ロールには、付与された権限およびロールから取り消された権限を付与できます。ロールは、ユーザーアカウントに対して付与または取り消すことができます。アカウントに適用可能なアクティブなロールは、アカウントに付与されているロールの中から選択でき、そのアカウントのセッション中に変更できます。詳細は、セクション6.2.10「ロールの使用」を参照してください。
- MySQL には、ユーザーアカウントカテゴリの概念が組み込まれ、システムユーザーと通常のユーザーは SYSTEM_USER 権限を持っているかどうかによって区別されるようになりました。セクション6.2.11「アカウントカテゴリ」を参照してください。
- 以前は、特定のスキーマを除き、グローバルに適用される権限を付与できませんでした。これは、partial_revokes システム変数が有効な場合に可能になりました。セクション6.2.12「部分取消しを使用した権限の制限」を参照してください。
- GRANT ステートメントには、ステートメントの実行に使用する権限コンテキストに関する追加情報を指定する AS user [WITH ROLE]句があります。この構文は SQL レベルで表示できますが、主な目的は、部分的な取消しによって課される権限付与者権限制限のすべてのノード間で均一なレプリケーションを有効にすることです。これにより、これらの制限がバイナリログに表示されます。セクション13.7.1.6「GRANT ステートメント」を参照してください。
- MySQL では、パスワード履歴に関する情報が保持されるようになり、以前のパスワードの再利用に関する制限が有効になりました。 DBA は、一定の変更回数または一定期間にわたって、以前使ったパスワードの再指定ができないように制限することができます。アカウント単位およびグローバルにパスワード再利用ポリシーを設定することができます。
  
  アカウントのパスワードを変更する場合、現在のパスワードの入力を要求することができるようになりました。これにより、DBA は、現在のパスワードを知らないユーザーがパスワードを変更するのを阻止できます。パスワード検証ポリシーは、グローバルにもアカウントごとにも設定できます。
  
  アカウントはデュアルパスワードを持つことができるようになりました。これにより、停止時間なしで複雑な複数サーバーシステムで段階的なパスワード変更をシームレスに実行できます。
  
  MySQL では、管理者がユーザーアカウントを構成できるようになり、パスワードの誤りによる連続したログイン失敗が多すぎると一時アカウントがロックされるようになりました。必要な失敗数とロック時間は、アカウントごとに構成できます。
  
  これらの新機能により、DBA はパスワード管理をより完全に制御できます。詳細は、セクション6.2.15「パスワード管理」を参照してください。
- OpenSSL を使用してコンパイルされた場合、MySQL で FIPS モードがサポートされるようになり、OpenSSL ライブラリおよび FIPS オブジェクトモジュールを実行時に使用できるようになりました。 FIPS モードでは、許容される暗号化アルゴリズムの制限や長いキー長の要件などの暗号化操作に条件が適用されます。セクション6.8「FIPS のサポート」を参照してください。
- サーバーが新しい接続に使用する TLS コンテキストは、実行時に再構成可能になりました。この機能は、SSL 証明書が期限切れになるまで実行されている MySQL サーバーを再起動しないようにする場合などに役立ちます。サーバー側のランタイム構成および暗号化された接続の監視を参照してください。
- OpenSSL 1.1.1 では、暗号化された接続用に TLS v1.3 プロトコルがサポートされ、MySQL 8.0.16 以上では、サーバーとクライアントの両方が OpenSSL 1.1.1 以上を使用してコンパイルされている場合に TLS v1.3 もサポートされます。セクション6.3.2「暗号化された接続 TLS プロトコルおよび暗号」を参照してください。
- MySQL は、名前付きパイプ上のクライアントに付与されるアクセス制御を、Windows での正常な通信に必要な最小値に設定するようになりました。新しい MySQL クライアントソフトウェアは、追加構成なしで名前付きパイプ接続を開くことができます。古いクライアントソフトウェアをすぐにアップグレードできない場合は、新しい named_pipe_full_access_group システム変数を使用して、名前付きパイプ接続を開くために必要な権限を Windows グループに付与できます。フルアクセスグループのメンバーシップは制限され、一時的である必要があります。
リソース管理. MySQL では、リソースグループの作成および管理がサポートされるようになり、グループで使用可能なリソースに従ってスレッドが実行されるように、サーバー内で実行されているスレッドを特定のグループに割り当てることができます。グループ属性を使用すると、そのリソースを制御して、グループ内のスレッドによるリソース消費を有効にしたり制限したりすることができます。 DBA は、様々なワークロードに応じてこれらの属性を変更できます。 >現在、CPU 時間は管理可能なリソースであり、CPU コア、ハイパースレッド、ハードウェアスレッドなどを含む用語として「「仮想 CPU」」の概念で表現されています。サーバーは起動時に使用可能な仮想 CPU の数を決定し、適切な権限を持つデータベース管理者はこれらの CPU をリソースグループに関連付け、スレッドをグループに割り当てることができます。詳細は、セクション5.1.16「リソースグループ」を参照してください。
テーブルの暗号化管理. 暗号化のデフォルトを定義して強制することで、テーブルの暗号化をグローバルに管理できるようになりました。 default_table_encryption 変数は、新しく作成されたスキーマおよび一般テーブルスペースの暗号化デフォルトを定義します。スキーマの暗号化のデフォルトは、スキーマの作成時に DEFAULT ENCRYPTION 句を使用して定義することもできます。デフォルトでは、テーブルは作成されたスキーマまたは一般テーブルスペースの暗号化を継承します。暗号化のデフォルトは、table_encryption_privilege_check 変数を有効にすることで適用されます。権限チェックは、default_table_encryption 設定とは異なる暗号化設定を使用してスキーマまたは一般テーブルスペースを作成または変更する場合、またはデフォルトのスキーマ暗号化とは異なる暗号化設定を使用してテーブルを作成または変更する場合に発生します。 TABLE_ENCRYPTION_ADMIN 権限では、table_encryption_privilege_check が有効な場合にデフォルトの暗号化設定をオーバーライドできます。詳細は、スキーマおよび一般テーブルスペースの暗号化デフォルトの定義を参照してください。
InnoDB の拡張機能. 次の InnoDB の拡張機能が追加されました。
- 現在の最大自動インクリメントカウンタ値は、値が変更されるたびに redo ログに書き込まれ、チェックポイントごとにエンジン固有のシステムテーブルに保存されます。これらの変更により、現在の最大自動インクリメントカウンタ値がサーバーの再起動後も保持されます。さらに、次のようになります:
  - サーバーを再起動しても、AUTO_INCREMENT = N テーブルオプションの効果は取り消されなくなりました。自動インクリメントカウンタを特定の値に初期化した場合、または自動インクリメントカウンタ値を大きな値に変更した場合、新しい値はサーバーの再起動後も保持されます。
  - ROLLBACK 操作の直後にサーバーを再起動しても、ロールバックされたトランザクションに割り当てられた自動増分値は再利用されなくなりました。
  - AUTO_INCREMENT カラムの値を現在の最大自動増分値より大きい値 (UPDATE 操作など) に変更すると、新しい値が永続化され、後続の INSERT 操作では新しい大きい値から始まる自動増分値が割り当てられます。
  詳細は、セクション15.6.1.6「InnoDB での AUTO_INCREMENT 処理」およびInnoDB AUTO_INCREMENT カウンタの初期化を参照してください。
- インデックスツリーの破損が発生すると、InnoDB は破損フラグを redo ログに書き込み、破損フラグを安全にクラッシュさせます。また、InnoDB は、インメモリー破損フラグデータを各チェックポイントのエンジン専用システムテーブルに書き込みます。リカバリ中、InnoDB は、インメモリーテーブルおよびインデックスオブジェクトを破損としてマークする前に、両方の場所から破損フラグを読み取り、結果をマージします。
- InnoDB memcached プラグインは、複数の get 操作 (単一の memcached クエリーで複数のキーと値のペアをフェッチ) および範囲クエリーをサポートしています。セクション15.20.4「InnoDB memcached の複数の get および Range クエリーのサポート」を参照してください。
- デッドロック検出を無効にするには、新しい動的変数 innodb_deadlock_detect を使用できます。同時実行性の高いシステムでは、多数のスレッドが同じロックを待機している場合、デッドロック検出によって速度が低下する可能性があります。デッドロック検出を無効にし、デッドロック発生時のトランザクションロールバックの innodb_lock_wait_timeout 設定に依存する方が効率的な場合があります。
- 新しい INFORMATION_SCHEMA.INNODB_CACHED_INDEXES テーブルには、インデックスごとに InnoDB バッファプールにキャッシュされたインデックスページの数がレポートされます。
- InnoDB 一時テーブルが共有一時テーブルスペースである ibtmp1 に作成されます。
- InnoDB tablespace encryption feature では、redo ログおよび undo ログデータの暗号化がサポートされています。 redo ログの暗号化およびundo ログの暗号化を参照してください。
- InnoDB は、SELECT ... FOR SHARE および SELECT ... FOR UPDATE のロック読取りステートメントで NOWAIT および SKIP LOCKED オプションをサポートしています。 NOWAIT では、リクエストされた行が別のトランザクションによってロックされている場合、ステートメントはただちに戻されます。 SKIP LOCKED では、ロックされた行が結果セットから削除されます。 NOWAIT および SKIP LOCKED による読取り同時実行性のロックを参照してください。
  
  SELECT ... FOR SHARE は SELECT ... LOCK IN SHARE MODE に置き換わりますが、LOCK IN SHARE MODE は下位互換性のために引き続き使用できます。ステートメントは同等です。ただし、FOR UPDATE および FOR SHARE は NOWAIT、SKIP LOCKED および OF tbl_name オプションをサポートしています。セクション13.2.10「SELECT ステートメント」を参照してください。
  
  OF tbl_name では、名前付きテーブルにロッククエリーが適用されます。
- ADD PARTITION, DROP PARTITION, COALESCE PARTITION, REORGANIZE PARTITION および REBUILD PARTITION ALTER TABLE オプションは、ネイティブパーティション化インプレース API でサポートされており、ALGORITHM={COPY|INPLACE} および LOCK 句とともに使用できます。
  
  ALGORITHM=INPLACE を使用した DROP PARTITION は、パーティションに格納されているデータを削除し、パーティションを削除します。ただし、ALGORITHM=COPY または old_alter_table=ON を使用した DROP PARTITION では、パーティションテーブルが再構築され、削除されたパーティションから互換性のある PARTITION ... VALUES 定義を持つ別のパーティションへのデータの移動が試行されます。別のパーティションに移動できないデータは削除されます。
- InnoDB ストレージエンジンは、独自のストレージエンジン固有のデータディクショナリではなく、MySQL データディクショナリを使用するようになりました。データディクショナリの詳細は、第14章「MySQL データディクショナリ」を参照してください。
- mysql システムテーブルおよびデータディクショナリテーブルは、MySQL データディレクトリの mysql.ibd という名前の単一の InnoDB テーブルスペースファイルに作成されるようになりました。以前は、これらのテーブルは mysql データベースディレクトリ内の個々の InnoDB テーブルスペースファイルに作成されていました。
- MySQL 8.0 では、次の undo テーブルスペースの変更が導入されています:
  - デフォルトでは、undo ログは、MySQL インスタンスの初期化時に作成される 2 つの undo テーブルスペースに存在するようになりました。 undo ログはシステムテーブルスペースに作成されなくなりました。
  - MySQL 8.0.14 では、CREATE UNDO TABLESPACE 構文を使用して、実行時に選択した場所に追加の undo テーブルスペースを作成できます。
    
    Press CTRL+C to copy
    
    CREATE UNDO TABLESPACE tablespace_name ADD DATAFILE 'file_name.ibu';
    
    CREATE UNDO TABLESPACE 構文を使用して作成された undo テーブルスペースは、DROP UNDO TABLESPACE 構文を使用して実行時に削除できます。
    
    Press CTRL+C to copy
    
    DROP UNDO TABLESPACE tablespace_name;
    
    ALTER UNDO TABLESPACE 構文を使用すると、undo テーブルスペースをアクティブまたは非アクティブとしてマークできます。
    
    Press CTRL+C to copy
    
    ALTER UNDO TABLESPACE tablespace_name SET {ACTIVE|INACTIVE};
    
    テーブルスペースの状態を示す STATE カラムが INFORMATION_SCHEMA.INNODB_TABLESPACES テーブルに追加されました。 undo テーブルスペースは、削除する前に empty 状態である必要があります。
  - innodb_undo_log_truncate 変数はデフォルトで有効になっています。
  - innodb_rollback_segments 変数は、undo テーブルスペースごとのロールバックセグメントの数を定義します。以前は、innodb_rollback_segments は MySQL インスタンスのロールバックセグメントの合計数を指定していました。この変更により、同時トランザクションに使用可能なロールバックセグメントの数が増加します。ロールバックセグメントを増やすと、同時トランザクションが undo ログに個別のロールバックセグメントを使用する可能性が高くなり、リソースの競合が少なくなります。
- バッファープールの事前フラッシュおよびフラッシュの動作に影響を与える変数のデフォルト値が変更されました:
  - innodb_max_dirty_pages_pct_lwm のデフォルト値は 10 になりました。前のデフォルト値の 0 は、バッファープールの事前フラッシュを無効にします。値 10 を指定すると、バッファープール内のダーティーページの割合が 10% を超える場合に事前フラッシュが有効になります。事前フラッシュを有効にすると、パフォーマンスの一貫性が向上します。
  - innodb_max_dirty_pages_pct のデフォルト値が 75 から 90 に増加しました。 InnoDB は、ダーティページの割合がこの値を超えないように、バッファプールからデータをフラッシュしようとします。デフォルト値を大きくすると、バッファープール内のダーティーページの割合が高くなります。
- デフォルトの innodb_autoinc_lock_mode 設定は 2 (インターリーブ) になりました。インターリーブロックモードでは、複数行の挿入をパラレルに実行できるため、同時実行性とスケーラビリティが向上します。新しい innodb_autoinc_lock_mode のデフォルト設定は、MySQL 5.7 のデフォルトのレプリケーションタイプがステートメントベースレプリケーションから行ベースレプリケーションに変更されたことを反映しています。ステートメントベースのレプリケーションでは、SQL ステートメントの実行順序に合わせて自動増分値が正しい順序で割り当てられるように、連続した自動増分ロックモード (前のデフォルト) が必要ですが、行ベースのレプリケーションでは SQL ステートメントの実行順序に影響しません。詳細は、InnoDB AUTO_INCREMENT のロックモードを参照してください。
  
  ステートメントベースレプリケーションを使用するシステムでは、新しい innodb_autoinc_lock_mode のデフォルト設定によって、シーケンシャルな自動インクリメント値に依存するアプリケーションが壊れる可能性があります。以前のデフォルトに戻すには、innodb_autoinc_lock_mode を 1 に設定します。
- 一般的なテーブルスペースの名前変更は、ALTER TABLESPACE ... RENAME TO 構文でサポートされています。
- デフォルトで無効になっている新しい innodb_dedicated_server 変数を使用すると、サーバーで検出されたメモリー量に応じて InnoDB で次のオプションを自動的に構成できます:
  - innodb_buffer_pool_size
  - innodb_log_file_size
  - innodb_flush_method
  このオプションは、専用サーバーで実行する MySQL サーバーインスタンスを対象としています。詳細は、セクション15.8.12「専用 MySQL Server の自動構成の有効化」を参照してください。
- 新しい INFORMATION_SCHEMA.INNODB_TABLESPACES_BRIEF ビューでは、InnoDB テーブルスペースの領域、名前、パス、フラグおよび領域タイプのデータが提供されます。
- MySQL にバンドルされている「zlib ライブラリ」バージョンは、バージョン 1.2.3 からバージョン 1.2.11 に引き上げられました。 MySQL は zlib ライブラリを使用して圧縮を実装します。
  
  InnoDB 圧縮テーブルを使用する場合、関連するアップグレードの影響については、セクション2.11.4「MySQL 8.0 での変更」を参照してください。
- シリアライズされたディクショナリ情報 (SDI) は、グローバル一時テーブルスペースおよび undo テーブルスペースファイルを除くすべての InnoDB テーブルスペースファイルに存在します。 SDI は、テーブルおよびテーブルスペースオブジェクトのシリアライズされたメタデータです。 SDI データが存在すると、メタデータの冗長性が提供されます。たとえば、データディクショナリが使用できなくなった場合、ディクショナリオブジェクトメタデータをテーブルスペースファイルから抽出できます。 SDI 抽出は、ibd2sdi ツールを使用して実行されます。 SDI データは JSON 形式で格納されます。
  
  SDI データをテーブルスペースファイルに含めると、テーブルスペースのファイルサイズが増加します。 SDI レコードには、デフォルトで 16KB の単一のインデックスページが必要です。ただし、SDI データは格納時に圧縮され、ストレージフットプリントが削減されます。
- InnoDB ストレージエンジンはアトミック DDL をサポートするようになり、操作中にサーバーが停止した場合でも、DDL 操作が完全にコミットまたはロールバックされるようになりました。詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」を参照してください。
- innodb_directories オプションを使用すると、サーバーがオフラインのときに、テーブルスペースファイルを新しい場所に移動またはリストアできます。詳細は、セクション15.6.3.6「サーバーがオフラインのときのテーブルスペースファイルの移動」を参照してください。
- 次の redo ロギング最適化が実装されました:
  - ユーザースレッドは、書込みを同期せずにログバッファに同時に書き込むことができるようになりました。
  - ユーザースレッドは、ダーティページを緩やかな順序でフラッシュリストに追加できるようになりました。
  - 専用ログスレッドは、システムバッファへのログバッファの書込み、ディスクへのシステムバッファのフラッシュ、書込みおよびフラッシュされた redo についてのユーザースレッドへの通知、緩和されたフラッシュリストの順序に必要なラグの維持およびチェックポイントの書込みを担当するようになりました。
  - フラッシュされた redo を待機しているユーザースレッドによるスピン遅延の使用を構成するためのシステム変数が追加されました:
    
    innodb_log_wait_for_flush_spin_hwm: フラッシュされた redo の待機中にユーザースレッドがスピンしなくなる最大平均ログフラッシュ時間を定義します。
    
    innodb_log_spin_cpu_abs_lwm: フラッシュされた redo の待機中にユーザースレッドがスピンしなくなる CPU 使用率の最小量を定義します。
    
    innodb_log_spin_cpu_pct_hwm: フラッシュされた redo の待機中にユーザースレッドがスピンしなくなる CPU 使用率の最大量を定義します。
  - innodb_log_buffer_size 変数が動的になり、サーバーの実行中にログバッファのサイズ変更が可能になりました。
  詳細は、セクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。
- MySQL 8.0.12 では、ラージオブジェクト (LOB) データに対する小さい更新で undo ロギングがサポートされているため、サイズが 100 バイト以下の LOB 更新のパフォーマンスが向上します。以前は、LOB の更新は少なくとも 1 つの LOB ページのサイズでしたが、数バイトしか変更できない更新には最適ではありませんでした。この拡張機能は、LOB データの部分更新のために MySQL 8.0.4 で追加されたサポートに基づいています。
- MySQL 8.0.12 では、ALGORITHM=INSTANT は次の ALTER TABLE 操作でサポートされています:
  - カラムの追加。この機能は、「「インスタント ADD COLUMN」」とも呼ばれます。制限が適用されます。セクション15.12.1「オンライン DDL 操作」を参照してください。
  - 仮想カラムの追加または削除。
  - カラムのデフォルト値の追加または削除。
  - ENUM または SET カラムの定義の変更。
  - インデックスタイプの変更。
  - テーブルの名前の変更。
  ALGORITHM=INSTANT をサポートする操作では、データディクショナリのメタデータのみが変更されます。テーブルに対するメタデータロックは行われず、テーブルデータは影響を受けず、操作は即時に行われます。明示的に指定しない場合、ALGORITHM=INSTANT はそれをサポートする操作によってデフォルトで使用されます。 ALGORITHM=INSTANT が指定されているがサポートされていない場合、操作はエラーですぐに失敗します。
  
  ALGORITHM=INSTANT をサポートする操作の詳細は、セクション15.12.1「オンライン DDL 操作」を参照してください。
- MySQL 8.0.13 の時点で、TempTable ストレージエンジンはバイナリラージオブジェクト (BLOB) 型のカラムの格納をサポートしています。この拡張により、BLOB データを含む一時テーブルを使用するクエリーのパフォーマンスが向上します。以前は、BLOB データを含む一時テーブルは、internal_tmp_disk_storage_engine によって定義されたディスク上のストレージエンジンに格納されていました。詳細は、セクション8.4.4「MySQL での内部一時テーブルの使用」を参照してください。
- MySQL 8.0.13 では、InnoDB の保存データ暗号化機能は一般的なテーブルスペースをサポートしています。以前は、file-per-table テーブルスペースのみを暗号化できました。一般テーブルスペースの暗号化をサポートするために、CREATE TABLESPACE および ALTER TABLESPACE 構文が拡張され、ENCRYPTION 句が追加されました。
  
  INFORMATION_SCHEMA.INNODB_TABLESPACES テーブルに、テーブルスペースが暗号化されているかどうかを示す ENCRYPTION カラムが含まれるようになりました。
  
  一般的なテーブルスペース暗号化操作の監視を許可するために、stage/innodb/alter tablespace (encryption) パフォーマンススキーマステージインストゥルメントが追加されました。
- innodb_buffer_pool_in_core_file 変数を無効にすると、InnoDB バッファープールページが除外され、コアファイルのサイズが小さくなります。この変数を使用するには、core_file 変数を有効にし、オペレーティングシステムで madvise() に対する MADV_DONTDUMP の POSIX 以外の拡張機能をサポートする必要があります。これは Linux 3.4 以降でサポートされています。詳細は、セクション15.8.3.7「コアファイルからのバッファープールページの除外」を参照してください。
- MySQL 8.0.13 では、オプティマイザによって作成されたユーザー作成の一時テーブルおよび内部一時テーブルは、一時テーブルスペースのプールからセッションに割り当てられたセッション一時テーブルスペースに格納されます。セッションが切断されると、その一時テーブルスペースは切り捨てられ、プールに解放されます。以前のリリースでは、一時テーブルはグローバル一時テーブルスペース (ibtmp1) に作成されており、一時テーブルの削除後にディスク領域がオペレーティングシステムに戻されませんでした。
  
  innodb_temp_tablespaces_dir 変数は、セッション一時テーブルスペースが作成される場所を定義します。デフォルトの場所は、データディレクトリ内の#innodb_temp ディレクトリです。
  
  INNODB_SESSION_TEMP_TABLESPACES テーブルは、セッション一時テーブルスペースに関するメタデータを提供します。
  
  グローバル一時テーブルスペース (ibtmp1) には、ユーザーが作成した一時テーブルに対する変更のロールバックセグメントが格納されるようになりました。
- MySQL 8.0.14 では、InnoDB はクラスタ化されたパラレルインデックス読取りをサポートしているため、CHECK TABLE のパフォーマンスを向上させることができます。この機能は、セカンダリインデックススキャンには適用されません。パラレルクラスタインデックス読取りを実行するには、innodb_parallel_read_threads セッション変数を 1 より大きい値に設定する必要があります。デフォルト値は 4 です。パラレルクラスタインデックス読取りの実行に使用されるスレッドの実際の数は、innodb_parallel_read_threads 設定またはスキャンするインデックスサブツリーの数 (いずれか小さい方) によって決まります。
- 8.0.14 では、innodb_dedicated_server 変数が有効な場合、ログファイルのサイズと数は、自動的に構成されたバッファプールサイズに従って構成されます。以前は、サーバーで検出されたメモリー量に従ってログファイルサイズが構成されており、ログファイルの数は自動的には構成されませんでした。
- 8.0.14 では、CREATE TABLESPACE ステートメントの ADD DATAFILE 句はオプションで、FILE 権限のないユーザーがテーブルスペースを作成できます。 ADD DATAFILE 句を指定せずに CREATE TABLESPACE ステートメントを実行すると、一意のファイル名でテーブルスペースデータファイルが暗黙的に作成されます。
- デフォルトでは、TempTable ストレージエンジンが占有しているメモリー量が temptable_max_ram 変数で定義されているメモリー制限を超えると、TempTable ストレージエンジンはメモリーマップされた一時ファイルのディスクからの割り当てを開始します。 MySQL 8.0.16 では、この動作は temptable_use_mmap 変数によって制御されます。 temptable_use_mmap を無効にすると、TempTable ストレージエンジンは、オーバーフローメカニズムとしてメモリーマップされたファイルの代わりに InnoDB ディスク上の内部一時テーブルを使用します。詳細は、内部一時テーブルストレージエンジンを参照してください。
- MySQL 8.0.16 では、InnoDB の保存データ暗号化機能は mysql システムテーブルスペースの暗号化をサポートしています。 mysql システムテーブルスペースには、mysql システムデータベースおよび MySQL データディクショナリテーブルが含まれます。詳細は、セクション15.13「InnoDB 保存データ暗号化」を参照してください。
- MySQL 8.0.16 で導入された innodb_spin_wait_pause_multiplier 変数を使用すると、スレッドが mutex または rw-lock の取得を待機したときに発生するスピンロックポーリング遅延の期間をより詳細に制御できます。遅延は、プロセッサアーキテクチャーごとに PAUSE 命令の期間の違いを考慮して、より細かくチューニングできます。詳細は、セクション15.8.8「スピンロックのポーリングの構成」を参照してください。
- 大規模なデータセットの InnoDB のパラレル読取りスレッドパフォーマンスは、読取りスレッドの使用率の向上、パラレルスキャン中に発生するプリフェッチアクティビティのための読取りスレッド I/O の削減、およびパーティションのパラレルスキャンのサポートにより、MySQL 8.0.17 で向上しました。
  
  パラレル読取りスレッド機能は、innodb_parallel_read_threads 変数によって制御されます。最大設定は 256 になりました。これは、すべてのクライアント接続のスレッドの合計数です。スレッド制限に達すると、接続は単一スレッドの使用にフォールバックします。
- MySQL 8.0.18 で導入された innodb_idle_flush_pct 変数を使用すると、アイドル期間中のページフラッシュに制限を設定できるため、ソリッドステートストレージデバイスの存続期間を延長できます。アイドル期間中のバッファフラッシュの制限を参照してください。
- ヒストグラム統計を生成するための InnoDB データの効率的なサンプリングは、MySQL 8.0.19 の時点でサポートされています。ヒストグラム統計分析を参照してください。
- MySQL 8.0.20 の時点では、二重書込みバッファ記憶域は二重書込みファイルにあります。以前のリリースでは、記憶域はシステムテーブルスペースに存在していました。システムテーブルスペースから記憶域を移動すると、書込み待機時間が短縮され、スループットが向上し、二重書込みバッファページの配置に関して柔軟性が提供されます。拡張二重書込みバッファ構成には、次のシステム変数が導入されました:
  - innodb_doublewrite_dir
    
    二重書込みバッファファイルディレクトリを定義します。
  - innodb_doublewrite_files
    
    二重書込みファイルの数を定義します。
  - innodb_doublewrite_pages
    
    バッチ書込みのスレッド当たりの二重書込みページの最大数を定義します。
  - innodb_doublewrite_batch_size
    
    バッチで書き込む二重書込みページの数を定義します。
  詳細は、セクション15.6.4「二重書き込みバッファー」を参照してください。
- ロックを待機しているトランザクションに優先順位を付ける競合対応トランザクションスケジューリング (CATS) アルゴリズムは、MySQL 8.0.20 で改善されました。トランザクションスケジュールの重み計算が完全に個別のスレッドで実行されるようになり、計算のパフォーマンスと精度が向上しました。
  
  トランザクションのスケジューリングにも使用されていた先入れ先出し (FIFO) アルゴリズムが削除されました。 FIFO アルゴリズムは CATS アルゴリズムの改善によって不要になりました。 FIFO アルゴリズムによって以前に実行されたトランザクションスケジューリングが CATS アルゴリズムによって実行されるようになりました。
  
  INFORMATION_SCHEMA.INNODB_TRX テーブルに TRX_SCHEDULE_WEIGHT カラムが追加され、CATS アルゴリズムによって割り当てられたトランザクションスケジューリングの重みの問い合わせが可能になりました。
  
  コードレベルのトランザクションスケジューリングイベントを監視するために、次の INNODB_METRICS カウンタが追加されました:
  - lock_rec_release_attempts
    
    レコードロックの解放の試行回数。
  - lock_rec_grant_attempts
    
    レコードロックの付与を試行する回数。
  - lock_schedule_refreshes
    
    トランザクションスケジュールの重みを更新するために待機グラフが分析された回数。
  詳細は、セクション15.7.6「トランザクションスケジューリング」を参照してください。
- MySQL 8.0.21 の時点では、テーブルおよび行リソースのロックキューへのアクセスを必要とする操作の同時実行性を向上させるために、ロックシステム mutex (lock_sys->mutex) がシャードラッチに置き換えられ、ロックキューがテーブルおよびページキューシャードのロックにグループ化され、各シャードが専用 mutex で保護されました。以前は、シングルロックシステム mutex はすべてのロックキューを保護していました。これは、同時実行性の高いシステムでの競合のポイントでした。新しいシャード実装では、ロックキューへのより詳細なアクセスが許可されます。
  
  ロックシステム mutex (lock_sys->mutex) は、次のシャードラッチに置き換えられました:
  - 64 個の読取り/書込みロックオブジェクト (rw_lock_t) で構成されるグローバルラッチ (lock_sys->latches.global_latch)。個々のロックキューにアクセスするには、共有グローバルラッチとロックキューシャードのラッチが必要です。すべてのロックキューへのアクセスを必要とする操作では、排他的なグローバルラッチが使用され、すべてのテーブルおよびページロックキューのシャードがラッチされます。
  - 512 の mutex の配列として実装されるテーブルシャードラッチ (lock_sys->latches.table_shards.mutexes)。各 mutex は 512 のテーブルロックキューシャードのいずれか専用です。
  - 512 個の mutex の配列として実装されるページシャードラッチ (lock_sys->latches.page_shards.mutexes)。各 mutex は 512 個のページロックキューシャードのいずれか専用です。
  単一ロックシステム相互排他ロックをモニタリングするためのパフォーマンススキーマ wait/synch/mutex/innodb/lock_mutex インストゥルメントは、新しいグローバルシャード、テーブルシャード、およびページシャードラッチをモニタリングするためのインストゥルメントに置き換えられました:
  - wait/synch/sxlock/innodb/lock_sys_global_rw_lock
  - wait/synch/mutex/innodb/lock_sys_table_mutex
  - wait/synch/mutex/innodb/lock_sys_page_mutex
- MySQL 8.0.21 では、DATA DIRECTORY 句を使用してデータディレクトリの外部で作成されたテーブルおよびテーブルパーティションのデータファイルは、InnoDB で認識されているディレクトリに制限されます。この変更により、データベース管理者はテーブルスペースデータファイルが作成される場所を制御でき、リカバリ中にデータファイルが検出されるようになります。
  
  一般テーブルスペースおよびファイルごとのテーブルスペースのデータファイル (.ibd ファイル) は、InnoDB で直接認識されないかぎり、undo テーブルスペースディレクトリ (innodb_undo_directory) に作成できなくなりました。
  
  既知のディレクトリは、datadir、innodb_data_home_dir および innodb_directories 変数で定義されているディレクトリです。
  
  file-per-table テーブルスペースに存在する InnoDB テーブルを切り捨てると、既存のテーブルスペースが削除され、新しいテーブルスペースが作成されます。 MySQL 8.0.21 では、InnoDB はデフォルトの場所に新しいテーブルスペースを作成し、現在のテーブルスペースディレクトリが不明な場合はエラーログに警告を書き込みます。 TRUNCATE TABLE で現在の場所にテーブルスペースを作成するには、TRUNCATE TABLE を実行する前に innodb_directories 設定にディレクトリを追加します。
- MySQL 8.0.21 では、ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG 構文を使用して redo ロギングを有効化および無効化できます。この機能は、新しい MySQL インスタンスにデータをロードするためのものです。 redo ロギングを無効にすると、redo ログの書込みが回避され、データのロードが高速化されます。
  
  新しい INNODB_REDO_LOG_ENABLE 権限では、redo ロギングの有効化および無効化が許可されます。
  
  新しい Innodb_redo_log_enabled ステータス変数を使用すると、redo ロギングステータスを監視できます。
  
  redo ロギングの無効化を参照してください。
- 起動時に、InnoDB は、テーブルスペースファイルが別の場所に移動された場合に備えて、データディクショナリに格納されているテーブルスペースファイルパスに対して既知のテーブルスペースファイルのパスを検証します。 MySQL 8.0.21 で導入された新しい innodb_validate_tablespace_paths 変数を使用すると、テーブルスペースパス検証を無効にできます。この機能は、テーブルスペースファイルを移動しない環境を対象としています。テーブルスペースパス検証を無効にすると、多数のテーブルスペースファイルがあるシステムでの起動時間が短縮されます。
  
  詳細は、セクション15.6.3.7「テーブルスペースパス検証の無効化」を参照してください。
- MySQL 8.0.21 の時点では、アトミック DDL をサポートするストレージエンジンでは、行ベースレプリケーションが使用されているときに、CREATE TABLE ... SELECT ステートメントがバイナリログに 1 つのトランザクションとして記録されます。以前は、2 つのトランザクションとしてログに記録されていました。1 つはテーブルの作成用、もう 1 つはデータの挿入用です。この変更により、CREATE TABLE ... SELECT ステートメントは行ベースレプリケーションに対して安全になり、GTID ベースレプリケーションでの使用が許可されるようになりました。詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」を参照してください。
- ビジー状態のシステムで undo テーブルスペースを切り捨てると、バッファプールから古い undo テーブルスペースページを削除し、新しい undo テーブルスペースの初期ページをディスクにフラッシュするフラッシュ操作が関連付けられているため、パフォーマンスに影響する可能性があります。この問題に対処するために、MySQL 8.0.21 でフラッシュ操作が削除されました。
  
  古い undo テーブルスペースページは、最近最も使用されなくなるか、次の完全チェックポイントで削除されると、パッシブに解放されます。新しい undo テーブルスペースの初期ページは、切捨て操作中にディスクにフラッシュされるのではなく redo ログに記録されるようになりました。これにより、undo テーブルスペースの切捨て操作の永続性も向上します。
  
  undo テーブルスペースの切捨て操作の数が多すぎることが原因で発生する潜在的な問題を回避するために、チェックポイント間の同じ undo テーブルスペースに対する切捨て操作は 64 に制限されるようになりました。この制限を超えると、undo テーブルスペースは非アクティブにできますが、次のチェックポイントまで切り捨てられません。
  
  廃止された undo 切捨てフラッシュ操作に関連付けられた INNODB_METRICS カウンタが削除されました。削除されたカウンタには次が含まれます: undo_truncate_sweep_count, undo_truncate_sweep_usec, undo_truncate_flush_count および undo_truncate_flush_usec。
  
  セクション15.6.3.4「undo テーブルスペース」を参照してください。
- MySQL 8.0.22 の時点では、新しい innodb_extend_and_initialize 変数を使用して、InnoDB が Linux 上の file-per-table および一般的なテーブルスペースに領域を割り当てる方法を構成できます。デフォルトでは、操作にテーブルスペースの追加領域が必要な場合、InnoDB はそのテーブルスペースにページを割り当て、それらのページに NULL を物理的に書き込みます。この動作は、新しいページが頻繁に割り当てられる場合のパフォーマンスに影響します。 Linux システムで innodb_extend_and_initialize を無効にして、新しく割り当てられたテーブルスペースページへの NULL の物理的な書込みを回避できます。 innodb_extend_and_initialize が無効になっている場合、領域は posix_fallocate() コールを使用して割り当てられます。このコールは、物理的に NULL を書き込まずに領域を予約します。
  
  posix_fallocate() 操作はアトミックではないため、テーブルスペースファイルへの領域の割当てとファイルメタデータの更新の間に障害が発生する可能性があります。このような障害が発生すると、新しく割り当てられたページは初期化されていない状態のままになり、InnoDB がこれらのページにアクセスしようとしたときに障害が発生する可能性があります。このシナリオを回避するために、InnoDB は新しいテーブルスペースページを割り当てる前に redo ログレコードを書き込みます。ページ割当て操作が中断されると、リカバリ中に redo ログレコードから操作がリプレイされます。
- MySQL 8.0.23 では、InnoDB は暗号化されたテーブルスペースに属する二重書込みファイルページの暗号化をサポートしています。ページは、関連付けられたテーブルスペースの暗号化キーを使用して暗号化されます。詳細は、セクション15.13「InnoDB 保存データ暗号化」を参照してください。
- MySQL 8.0.23 で導入された temptable_max_mmap 変数は、TempTable ストレージエンジンが内部一時テーブルデータのディスクへの格納を開始する前に、メモリーマップ (MMAP) ファイルから割り当てることができるメモリーの最大量を定義します。 0 に設定すると、MMAP ファイルからの割り当てが無効になります。詳細は、セクション8.4.4「MySQL での内部一時テーブルの使用」を参照してください。
- MySQL 8.0.23 で導入された AUTOEXTEND_SIZE オプションは、テーブルスペースが一杯になったときに InnoDB がテーブルスペースのサイズを拡張する量を定義し、テーブルスペースのサイズを大きく拡張できるようにします。 AUTOEXTEND_SIZE オプションは、CREATE TABLE, ALTER TABLE, CREATE TABLESPACE および ALTER TABLESPACE ステートメントでサポートされています。詳細は、セクション15.6.3.9「テーブルスペースの AUTOEXTEND_SIZE 構成」を参照してください。
  
  AUTOEXTEND_SIZE サイズカラムが INFORMATION_SCHEMA.INNODB_TABLESPACES テーブルに追加されました。
文字セットのサポート. デフォルトの文字セットが latin1 から utf8mb4 に変更されました。 utf8mb4 文字セットには、MySQL の Unicode で使用可能な最初の日本語固有の照合である utf8mb4_ja_0900_as_cs を含む、いくつかの新しい照合順序があります。詳細は、セクション10.10.1「Unicode 文字セット」を参照してください。
JSON の拡張機能. MySQL JSON 機能が次のように拡張または追加されました:
- JSON_EXTRACT() の結果で JSON_UNQUOTE() をコールするのと同等の ->> (インラインパス) 演算子が追加されました。
  
  これは、MySQL 5.7 で導入されたカラムパス演算子 -> の改良です。col->>"$.path"は JSON_UNQUOTE(col->"$.path") と同等です。インラインパス演算子は、SELECT カラムリスト、WHERE 句と HAVING 句、ORDER BY 句と GROUP BY 句など、JSON_UNQUOTE(JSON_EXTRACT()) を使用できる任意の場所で使用できます。詳細は、演算子の説明および JSON パス構文を参照してください。
- 2 つの JSON 集計関数 JSON_ARRAYAGG() および JSON_OBJECTAGG() が追加されました。 JSON_ARRAYAGG() は、引数としてカラムまたは式を取り、結果を単一の JSON 配カラムとして集計します。式は任意の MySQL データ型に評価できます。これは JSON 値である必要はありません。 JSON_OBJECTAGG() では、キーおよび値として解釈される 2 つのカラムまたは式が使用され、結果は単一の JSON オブジェクトとして返されます。詳細および例については、セクション12.20「集計関数」を参照してください。
- 既存の JSON 値を読みやすい形式で出力する JSON ユーティリティ関数 JSON_PRETTY() が追加されました。各 JSON オブジェクトメンバーまたは配列値は別々の行に出力され、子オブジェクトまたは配列はその親に対して 2 文字のスペースでインデントされます。
  
  この関数は、JSON 値として解析できる文字列でも機能します。
  
  詳細および例については、セクション12.18.8「JSON ユーティリティ関数」を参照してください。
- ORDER BY を使用してクエリーで JSON 値をソートする場合、各値は固定サイズの 1K の一部ではなく、ソートキーの可変長部分で表されるようになりました。多くの場合、これにより過剰な使用量が削減される可能性があります。たとえば、スカラー INT または BIGINT 値には、実際には非常に少ないバイト数が必要であるため、この領域の残り (最大 90% 以上) はパディングによって占有されています。この変更には、パフォーマンスに関して次の利点があります:
  - ソートバッファー領域がより効率的に使用されるようになったため、ファイルソートは固定長のソートキーを使用する場合と同じくらい早くディスクにフラッシュする必要はありません。つまり、メモリー内でソートできるデータが増え、不要なディスクアクセスが回避されます。
  - 短いキーは長いキーよりも迅速に比較できるため、パフォーマンスが著しく向上します。これは、メモリー内で完全に実行されるソートと、ディスクへの書込みおよびディスクからの読取りが必要なソートに当てはまります。
- JSON カラム値の部分的なインプレース更新のサポートが MySQL 8.0.2 に追加されました。これは、JSON カラムの更新時に以前に行ったように、既存の JSON 値を完全に削除してその場所に新しい JSON 値を書き込むよりも効率的です。この最適化を適用するには、JSON_SET()、JSON_REPLACE() または JSON_REMOVE() を使用して更新を適用する必要があります。更新中の JSON ドキュメントに新しい要素を追加することはできません。ドキュメント内の値は、更新前よりも多くの領域を取ることはできません。要件の詳細は、JSON 値の部分更新を参照してください。
  
  JSON ドキュメントの部分更新はバイナリログに書き込むことができ、完全な JSON ドキュメントをロギングするよりも少ない領域を占有します。ステートメントベースのレプリケーションが使用されている場合、部分更新は常にそのように記録されます。これを行ベースのレプリケーションで使用するには、まず binlog_row_value_options=PARTIAL_JSON を設定する必要があります。詳細は、この変数の説明を参照してください。
- JSON ユーティリティ関数 JSON_STORAGE_SIZE() および JSON_STORAGE_FREE() が追加されました。 JSON_STORAGE_SIZE() は、部分更新の前に JSON ドキュメントのバイナリ表現に使用される記憶領域をバイト単位で返します (前の項目を参照)。 JSON_STORAGE_FREE() では、JSON_SET() または JSON_REPLACE() を使用して部分的に更新された後、JSON 型のテーブルのカラムに残っている領域の量が表示されます。新しい値のバイナリ表現が前の値より小さい場合、これはゼロより大きくなります。
  
  これらの各関数は、JSON ドキュメントの有効な文字列表現も受け入れます。このような値の場合、JSON_STORAGE_SIZE() は JSON ドキュメントへの変換後にバイナリ表現で使用される領域を返します。 JSON ドキュメントの文字列表現を含む変数の場合、JSON_STORAGE_FREE() はゼロを返します。いずれの関数も、その (null 以外の) 引数を有効な JSON ドキュメントとして解析できない場合はエラーを生成し、引数が NULL の場合は NULL を生成します。
  
  詳細および例については、セクション12.18.8「JSON ユーティリティ関数」を参照してください。
  
  JSON_STORAGE_SIZE() および JSON_STORAGE_FREE() は、MySQL 8.0.2 に実装されました。
- MySQL 8.0.2 では、XPath 式で $[1 to 5]などの範囲をサポートするようになりました。また、このバージョンでの last キーワードと相対アドレス指定のサポートが追加され、$[last]は常に配列の最後 (最も高い番号) の要素を選択し、$[last-1]は最後の 1 つ前の要素を選択するようになりました。last およびそれを使用する式は、範囲定義に含めることもできます。たとえば、$[last-2 to last-1]は、配列の最後を除いた手前 2 つの要素を返します。追加情報および例については、JSON 値の検索および変更を参照してください。
- RFC 7396 に準拠するための JSON マージ関数が追加されました。 JSON_MERGE_PATCH() は、2 つの JSON オブジェクトで使用される場合、次のセットの結合をメンバーとして持つ単一の JSON オブジェクトにマージします:
  - 2 番目のオブジェクトに同じキーを持つメンバがない最初のオブジェクトの各メンバ。
  - 最初のオブジェクトに同じキーを持つメンバーが存在せず、その値が JSON null リテラルではない、2 番目のオブジェクトの各メンバー。
  - 両方のオブジェクトに存在し、2 番目のオブジェクトの値が JSON null リテラルではないキーを持つ各メンバー。
  この作業の一環として、JSON_MERGE() 関数の名前は JSON_MERGE_PRESERVE() に変更されました。 JSON_MERGE() は、MySQL 8.0 で JSON_MERGE_PRESERVE() のエイリアスとして引き続き認識されますが、非推奨になり、MySQL の将来のバージョンで削除される予定です。
  
  詳細および例については、セクション12.18.4「JSON 値を変更する関数」を参照してください。
- RFC 7159 およびほとんどの JavaScript パーサーと同様の、重複キーの「「最後の重複キー優先」」正規化を実装しました。この動作の例を次に示します。ここでは、キー x を持つ右端のメンバーのみが保持されます:
```
Press CTRL+C to copy
 
mysql> SELECT JSON_OBJECT('x', '32', 'y', '[true, false]',
     >                     'x', '"abc"', 'x', '100') AS Result;
+------------------------------------+
| Result                             |
+------------------------------------+
| {"x": "100", "y": "[true, false]"} |
+------------------------------------+
1 row in set (0.00 sec)
```
  次の例に示すように、MySQL JSON カラムに挿入された値もこの方法で正規化されます:
```
Press CTRL+C to copy
 
mysql> CREATE TABLE t1 (c1 JSON);

mysql> INSERT INTO t1 VALUES ('{"x": 17, "x": "red", "x": [3, 5, 7]}');

mysql> SELECT c1 FROM t1;
+------------------+
| c1               |
+------------------+
| {"x": [3, 5, 7]} |
+------------------+
```
  これは、このような場合に「「最初の重複キー優先」」アルゴリズムが使用されていた以前のバージョンの MySQL とは互換性のない変更です。
  
  詳細および例については、JSON 値の正規化、マージおよび自動ラップを参照してください。
- MySQL 8.0.4 に JSON_TABLE() 関数が追加されました。この関数は、JSON データを受け入れ、指定されたカラムを持つリレーショナルテーブルとして戻します。
  
  この関数の構文は、JSON_TABLE(expr, path COLUMNS column_list) [AS] alias) です。ここで、expr は JSON データを返す式、path はソースに適用される JSON パス、column_list はカラム定義のリストです。次に例を示します:
```
Press CTRL+C to copy
 
mysql> SELECT *
    -> FROM
    ->   JSON_TABLE(
    ->     '[{"a":3,"b":"0"},{"a":"3","b":"1"},{"a":2,"b":1},{"a":0},{"b":[1,2]}]',
    ->     "$[*]" COLUMNS(
    ->       rowid FOR ORDINALITY,
    ->
    ->       xa INT EXISTS PATH "$.a",
    ->       xb INT EXISTS PATH "$.b",
    ->
    ->       sa VARCHAR(100) PATH "$.a",
    ->       sb VARCHAR(100) PATH "$.b",
    ->
    ->       ja JSON PATH "$.a",
    ->       jb JSON PATH "$.b"
    ->     )
    ->   ) AS  jt1;
+-------+------+------+------+------+------+--------+
| rowid | xa   | xb   | sa   | sb   | ja   | jb     |
+-------+------+------+------+------+------+--------+
|     1 |    1 |    1 | 3    | 0    | 3    | "0"    |
|     2 |    1 |    1 | 3    | 1    | "3"  | "1"    |
|     3 |    1 |    1 | 2    | 1    | 2    | 1      |
|     4 |    1 |    0 | 0    | NULL | 0    | NULL   |
|     5 |    0 |    1 | NULL | NULL | NULL | [1, 2] |
+-------+------+------+------+------+------+--------+
```
  JSON ソース式には、JSON リテラル、テーブルのカラム、JSON_EXTRACT(t1, data, '$.post.comments') などの JSON を返す関数コールなど、有効な JSON ドキュメントを生成する任意の式を指定できます。詳細は、セクション12.18.6「JSON テーブル関数」を参照してください。
データ型のサポート. MySQL では、データ型指定でのデフォルト値としての式の使用がサポートされるようになりました。これには、以前はデフォルト値を割り当てることができなかった BLOB, TEXT, GEOMETRY および JSON データ型のデフォルト値としての式の使用が含まれます。詳細は、セクション11.6「データ型デフォルト値」を参照してください。
オプティマイザ. 次のオプティマイザ拡張機能が追加されました:
- MySQL で不可視インデックスがサポートされるようになりました。不可視のインデックスはオプティマイザではまったく使用されませんが、それ以外の場合は正常にメンテナンスされます。インデックスはデフォルトで可視化されます。不可視のインデックスを使用すると、インデックスが必要になった場合に元に戻す必要がある破壊的な変更を行わずに、クエリーのパフォーマンスに対するインデックスの削除の影響をテストできます。セクション8.3.12「不可視のインデックス」を参照してください。
- MySQL で降順インデックスがサポートされるようになりました: インデックス定義内の DESC は無視されなくなりましたが、キー値が降順で格納されます。以前は、インデックスを逆の順序でスキャンできましたが、パフォーマンスが低下していました。降順インデックスは順にスキャンできるため、より効率的です。降順インデックスを使用すると、オプティマイザが複数カラムインデックスを使用できるようになります (最も効率的なスキャン順序で一部のカラムに昇順が混在し、他のカラムに降順が混在している場合)。セクション8.3.13「降順インデックス」を参照してください。
- MySQL では、カラム値ではなく式の値をインデックス付けする関数インデックスキー部分の作成がサポートされるようになりました。関数キーパーツを使用すると、JSON 値など、インデックス化できない値のインデックス化が可能です。詳細は、セクション13.1.15「CREATE INDEX ステートメント」を参照してください。
- MySQL 8.0.14 以降では、定数リテラル式から発生する自明の WHERE 条件は、後で最適化するのではなく、準備中に削除されます。このプロセスの前半で条件を削除すると、次のような簡易条件を持つ外部結合を含むクエリーの結合を簡略化できます:
```
Press CTRL+C to copy
 
SELECT * FROM t1 LEFT JOIN t2 ON condition_1 WHERE condition_2 OR 0 = 1
```
  オプティマイザは、準備中に 0 = 1 が常に false であることを確認し、OR 0 = 1 を冗長にして削除し、次の状態のままにします:
```
Press CTRL+C to copy
 
SELECT * FROM t1 LEFT JOIN t2 ON condition_1 where condition_2
```
  これで、オプティマイザは、次のようにクエリーを内部結合としてリライトできます:
```
Press CTRL+C to copy
 
SELECT * FROM t1 LEFT JOIN t2 WHERE condition_1 AND condition_2
```
  詳細は、セクション8.2.1.9「外部結合の最適化」を参照してください。
- MySQL 8.0.16 以降では、MySQL は最適化時に定数折りたたみを使用して、実行時に行ごとに行うのではなく、カラムと定数値 (定数がカラムの範囲外またはカラムのタイプに対する範囲境界) の比較を処理できます。たとえば、TINYINT UNSIGNED カラム c を含むテーブル t の場合、オプティマイザは WHERE c < 256 などの条件を WHERE 1 にリライト (および条件を完全に最適化) したり、WHERE c >= 255 を WHERE c = 255 にリライトできます。
  
  詳しくはセクション8.2.1.14「定数 - フォールディングの最適化」,をご覧ください。
- MySQL 8.0.16 以降、IN サブクエリーで使用される準結合最適化を EXISTS サブクエリーにも適用できるようになりました。また、オプティマイザでは、サブクエリーにアタッチされた WHERE 条件のわずかな相関等価述語が解除され、IN サブクエリーの式と同様に処理できるようになりました。これは、EXISTS サブクエリーと IN サブクエリーの両方に適用されます。
  
  詳細は、セクション8.2.2.1「準結合変換による IN および EXISTS サブクエリー述語の最適化」を参照してください。
- MySQL 8.0.17 では、サーバーはコンテキスト化フェーズ中に不完全な SQL 述語 (つまり、value がカラム名または定数式で、比較演算子が使用されていない WHERE value 形式の述語) を WHERE value <> 0 として内部的にリライトするため、クエリーリゾルバ、クエリーオプティマイザおよびクエリーエグゼキュータは完全な述語のみ処理すればよくなりました。
  
  この変更の表示可能な効果の 1 つは、ブール値の場合、EXPLAIN 出力に 1 および 0 ではなく true および false が表示されるようになったことです。
  
  この変更によるもう 1 つの効果は、SQL ブールコンテキストで JSON 値を評価すると、JSON 整数 0 に対して暗黙の比較が行われることです。次のように作成および移入されたテーブルについて考えてみます:
```
Press CTRL+C to copy
 
mysql> CREATE TABLE test (id INT, col JSON);

mysql> INSERT INTO test VALUES (1, '{"val":true}'), (2, '{"val":false}');
```
  以前は、IS TRUE を使用した次のクエリーに示すように、サーバーは、抽出された true または false の値を SQL ブールコンテキストで比較するときに SQL ブールに変換しようとしました:
```
Press CTRL+C to copy
 
mysql> SELECT id, col, col->"$.val" FROM test WHERE col->"$.val" IS TRUE;
+------+---------------+--------------+
| id   | col           | col->"$.val" |
+------+---------------+--------------+
|    1 | {"val": true} | true         |
+------+---------------+--------------+
```
  MySQL 8.0.17 以降では、抽出された値を JSON 整数 0 と暗黙の照合により、異なる結果をもたらします:
```
Press CTRL+C to copy
 
mysql> SELECT id, col, col->"$.val" FROM test WHERE col->"$.val" IS TRUE;
+------+----------------+--------------+
| id   | col            | col->"$.val" |
+------+----------------+--------------+
|    1 | {"val": true}  | true         |
|    2 | {"val": false} | false        |
+------+----------------+--------------+
```
  MySQL 8.0.21 以降では、次に示すように、抽出された値に対して JSON_VALUE() を使用して、テストを実行する前に型変換を実行できます:
```
Press CTRL+C to copy
 
mysql> SELECT id, col, col->"$.val" FROM test
    ->     WHERE JSON_VALUE(col, "$.val" RETURNING UNSIGNED) IS TRUE;
+------+---------------+--------------+
| id   | col           | col->"$.val" |
+------+---------------+--------------+
|    1 | {"val": true} | true         |
+------+---------------+--------------+
```
  また、MySQL 8.0.21 以降では、この方法で SQL ブールコンテキストの抽出された値を比較する際に、サーバーによって警告「Evaluating a JSON value in SQL boolean context does an implicit comparison against JSON integer 0; if this is not what you want, consider converting JSON to an SQL numeric type with JSON_VALUE RETURNING when comparing extracted values in an SQL boolean context in this manner. (SQL ブールコンテキストで JSON 値を評価すると、JSON の整数 0 との暗黙の比較が行われます。想定と違う場合は、JSON_VALUE RETURNING を使用して JSON を SQL 数値型に変換することを検討してください)」が提供されます。
- MySQL 8.0.17 以降では、NOT IN (subquery) または NOT EXISTS (subquery) を含む WHERE 条件は内部的にアンチ結合に変換されます。 (アンチ結合は、結合先のテーブルにある、結合条件に一致する行以外のすべての行を返します。) サブクエリーのテーブルが最優先で処理されるようになったことで、遅いサブクエリーが削除されて結果的に問い合わせの実行が速くなります。
  
  これは、外部結合用の既存の IS NULL (Not exists) 最適化に似ており、それを再利用したものです。EXPLAIN 追加情報を参照してください。
- MySQL 8.0.21 以降、多くの場合、単一テーブルの UPDATE ステートメントまたは DELETE ステートメントで準結合変換またはサブクエリーの実体化を使用できるようになりました。これは、次に示す形式のステートメントに適用されます:
  - UPDATE t1 SET t1.a=value WHERE t1.a IN (SELECT t2.a FROM t2)
  - DELETE FROM t1 WHERE t1.a IN (SELECT t2.a FROM t2)
  これは、次の条件を満たす単一テーブルの UPDATE または DELETE に対して実行できます:
  - UPDATE ステートメントまたは DELETE ステートメントでは、[NOT] IN 述語または[NOT] EXISTS 述語を持つサブクエリーが使用されます。
  - ステートメントには ORDER BY 句がなく、LIMIT 句もありません。
    
    (UPDATE および DELETE の複数テーブルバージョンでは、ORDER BY または LIMIT はサポートされていません。)
  - ターゲットテーブルでは、読取り/書込み削除はサポートされていません (NDB テーブルにのみ関連します)。
  - 準結合またはサブクエリーの実体化は、サブクエリーに含まれるヒントおよび optimizer_switch の値に基づいて実行できます。
  準結合最適化が適格な単一テーブル DELETE または UPDATE に使用されている場合、これはオプティマイザトレースに表示されます: 複数テーブルのステートメントの場合はトレースに join_optimization オブジェクトがありますが、単一テーブルのステートメントの場合はありません。変換は、EXPLAIN FORMAT=TREE または EXPLAIN ANALYZE の出力にも表示されます。単一テーブルのステートメントは <not executable by iterator executor> を示し、複数テーブルのステートメントは完全な計画をレポートします。
  
  MySQL 8.0.21 以降では、REPEATABLE READ より弱いトランザクション分離レベルのために、InnoDB テーブルを使用する複数テーブルの UPDATE ステートメントで半一貫性読取りがサポートされます。
- ハッシュ結合パフォーマンスの向上. MySQL 8.0.23 はハッシュ結合に使用されるハッシュテーブルを再実装するため、ハッシュ結合のパフォーマンスがいくつか向上します。この作業には問題 (Bug #31516149、Bug #99933) の修正が含まれており、結合バッファ (join_buffer_size) に割り当てられたメモリーの約 2/3 のみをハッシュ結合で実際に使用できます。
  
  通常、新しいハッシュテーブルは古いハッシュテーブルより高速で、位置合せ、キー/値、および同等のキーが多数あるシナリオで使用されるメモリーが少なくなります。また、ハッシュテーブルのサイズが増えると、サーバーは古いメモリーを解放できるようになりました。
共通テーブル式. MySQL では、非再帰テーブルと再帰テーブルの両方の共通テーブル式がサポートされるようになりました。共通テーブル式を使用すると、名前付き一時結果セットを使用できます。この結果セットは、SELECT ステートメントおよびその他の特定のステートメントの前に WITH 句を記述する形で実装されます。詳細は、セクション13.2.15「WITH (共通テーブル式)」を参照してください。

MySQL 8.0.19 では、再帰的共通テーブル式 (CTE) の再帰的 SELECT 部分で LIMIT 句がサポートされています。 LIMIT と OFFSET もサポートされています。詳しくは再帰的な共通テーブル式,をご覧ください。
ウィンドウ関数. MySQL では、クエリーの各行について、その行に関連する行を使用して計算を実行するウィンドウ関数がサポートされるようになりました。これには、RANK()、LAG()、NTILE() などの関数が含まれます。また、複数の既存の集計関数をウィンドウ関数 (SUM() や AVG() など) として使用できるようになりました。詳細は、セクション12.21「ウィンドウ関数」を参照してください。
ラテラル導出テーブル. 導出テーブルの前に LATERAL キーワードを付けて、同じ FROM 句内の前述のテーブルのカラムを参照 (依存) できるように指定できるようになりました。ラテラル導出テーブルを使用すると、非ラテラル導出テーブルでは実行できない特定の SQL 操作や、より効率的な回避策が必要になる可能性があります。セクション13.2.11.9「ラテラル導出テーブル」を参照してください。
単一テーブル DELETE ステートメントのエイリアス. MySQL 8.0.16 以降では、単一テーブルの DELETE ステートメントでテーブルのエイリアスの使用がサポートされます。
正規表現のサポート. 以前は、MySQL は Henry Spencer 正規表現ライブラリを使用して正規表現演算子 (REGEXP、RLIKE) をサポートしていました。完全な Unicode サポートを提供し、マルチバイトセーフな International Components for Unicode (ICU) を使用して、正規表現のサポートが再実装されました。 REGEXP_LIKE() 関数は、REGEXP 演算子および RLIKE 演算子 (現在はその関数のシノニム) の方法で正規表現の一致を実行します。また、REGEXP_INSTR()、REGEXP_REPLACE() および REGEXP_SUBSTR() の各関数を使用して、一致する位置を検索し、部分文字列の置換および抽出をそれぞれ実行できます。 regexp_stack_limit および regexp_time_limit システム変数は、照合エンジンによるリソース消費を制御します。詳細については、セクション12.8.2「正規表現」を参照してください。正規表現を使用するアプリケーションが実装の変更の影響を受ける方法の詳細は、正規表現の互換性に関する考慮事項を参照してください。
内部一時テーブル. TempTable ストレージエンジンは、インメモリー内部一時テーブルのデフォルトエンジンとして MEMORY ストレージエンジンを置き換えます。 TempTable ストレージエンジンは、VARCHAR および VARBINARY カラムの効率的なストレージを提供します。 internal_tmp_mem_storage_engine セッション変数は、インメモリー内部一時テーブルのストレージエンジンを定義します。許可される値は、TempTable (デフォルト) および MEMORY です。 temptable_max_ram 変数は、データがディスクに格納される前に TempTable ストレージエンジンが使用できるメモリーの最大量を定義します。
ロギング. エラーロギングは、MySQL コンポーネントアーキテクチャを使用するようにリライトされました。従来のエラーロギングは組込みコンポーネントを使用して実装され、システムログを使用したロギングはロード可能コンポーネントとして実装されます。また、ロード可能な JSON ログライターも使用できます。有効にするログコンポーネントを制御するには、log_error_services システム変数を使用します。詳細は、セクション5.4.2「エラーログ」を参照してください。
バックアップロック. 新しいタイプのバックアップロックでは、オンラインバックアップ中に DML が許可されますが、一貫性のないスナップショットになる可能性がある操作は防止されます。新しいバックアップロックは、LOCK INSTANCE FOR BACKUP および UNLOCK INSTANCE 構文でサポートされています。これらのステートメントを使用するには、BACKUP_ADMIN 権限が必要です。
レプリケーション. MySQL レプリケーションが次のように拡張されました:
- MySQL レプリケーションでは、コンパクトなバイナリ形式を使用した JSON ドキュメントへの部分的な更新のバイナリロギングをサポートし、完全な JSON ドキュメントを記録するよりもログの領域を節約できるようになりました。このようなコンパクトロギングは、ステートメントベースのロギングが使用されているときに自動的に実行され、新しい binlog_row_value_options システム変数を PARTIAL_JSON に設定することで有効にできます。詳細は、JSON 値の部分更新および binlog_row_value_options の説明を参照してください。
接続管理. MySQL Server では、管理接続専用に TCP/IP ポートを構成できるようになりました。これは、通常接続用のネットワークインターフェースで許可されていた追加の管理用接続 (max_connections の接続がすでに確立されている場合でも 1 つだけ追加で管理接続が可能) の代替となります。セクション5.1.12.1「接続インタフェース」を参照してください。

MySQL では、サーバーへの接続を介して送信されるバイト数を最小限に抑えるために、圧縮の使用をより詳細に制御できるようになりました。以前は、特定の接続が zlib 圧縮アルゴリズムを圧縮解除または使用していました。 zstd アルゴリズムを使用して、zstd 接続の圧縮レベルを選択することもできます。許可される圧縮アルゴリズムは、サーバー側でも接続元 (クライアントプログラムおよび、ソース/レプリカレプリケーションやグループレプリケーションに参加しているサーバー) の側でも設定することができます。詳細は、セクション4.2.8「接続圧縮制御」を参照してください。
構成. MySQL 全体で許可されているホスト名の最大長は、以前の 60 文字の制限から 255 文字まで ASCII 文字になりました。これは、データディクショナリ内のホスト名関連のカラム、mysql システムスキーマ、パフォーマンススキーマ、INFORMATION_SCHEMA および sys スキーマ、MASTER_HOST 値 (CHANGE MASTER TO 属性用)、Host カラム (SHOW PROCESSLIST ステートメントの出力内)、アカウント名内のホスト名 (account-management ステートメントおよび DEFINER 属性内で使用など)、およびホスト名関連のシステム変数に適用されます。

注意事項:
- 許可されるホスト名の長さを増やすと、ホスト名カラムにインデックスがあるテーブルに影響する可能性があります。たとえば、ホスト名をインデックス付けする mysql システムスキーマのテーブルには、長いインデックス値を格納するために DYNAMIC の明示的な ROW_FORMAT 属性が含まれるようになりました。
- ファイル名を値として持つ構成設定の中には、サーバーのホスト名に基づいて構築されるものがあります。許容される値は、255 文字のホスト名を含むような長いファイル名を許可していないケースのように、基礎となるオペレーティングシステムによって制約されます。これは、general_log_file, log_error, pid_file, relay_log、slow_query_log_file システム変数および対応するオプションに影響します。ホスト名に基づく値が OS に対して長すぎる場合は、明示的に短い値を指定する必要があります。
- サーバーで 255 文字のホスト名がサポートされるようになりましたが、--ssl-mode=VERIFY_IDENTITY オプションを使用して確立されるサーバーへの接続は、OpenSSL でサポートされるホスト名の最大長によって制約されます。ホスト名の一致は、SSL 証明書の 2 つのフィールドに関連し、最大長は次のとおりです: 共通名: 最大長 64;サブジェクト代替名: RFC#1034 に従った最大長。
プラグイン. 以前は、MySQL プラグインは C または C++ で記述できました。プラグインで使用される MySQL ヘッダーファイルに C++ コードが含まれるようになりました。つまり、プラグインは C ではなく C++ で記述する必要があります。
C API. MySQL C API では、MySQL サーバーとのノンブロック通信用の非同期関数がサポートされるようになりました。各関数は、既存の同期関数に対応する非同期関数です。同期関数は、サーバー接続からの読取りまたはサーバー接続への書込みを待機する必要がある場合にブロックします。非同期関数を使用すると、アプリケーションはサーバー接続での作業を続行する準備ができているかどうかを確認できます。そうでない場合、アプリケーションが他の作業を行った後で、再確認することができます。 C API Asynchronous Interfaceを参照してください。
キャストの追加のターゲットタイプ. CAST() および CONVERT() の関数は、DOUBLE、FLOAT および REAL 型への変換をサポートするようになりました。 MySQL 8.0.17 で追加されました。セクション12.11「キャスト関数と演算子」を参照してください。
JSON スキーマ検証. MySQL 8.0.17 には、JSON ドキュメントを再度 JSON スキーマで検証するための JSON_SCHEMA_VALID() および JSON_SCHEMA_VALIDATION_REPORT() の 2 つの関数が追加されています。 JSON_SCHEMA_VALID() は、ドキュメントがスキーマに対して検証される場合は TRUE (1) を戻し、検証されない場合は FALSE (0) を戻します。 JSON_SCHEMA_VALIDATION_REPORT() は、検証の結果に関する詳細情報を含む JSON ドキュメントを返します。次のステートメントは、これらの両方の関数に適用されます:
- スキーマは、JSON スキーマ仕様のドラフト 4 に準拠する必要があります。
- required 属性がサポートされています。
- 外部リソースおよび $ref キーワードはサポートされていません。
- 正規表現パターンがサポートされています。無効なパターンは暗黙的に無視されます。
詳細および例については、セクション12.18.7「JSON スキーマ検証関数」を参照してください。
複数値インデックス. MySQL 8.0.17 以降、InnoDB では複数値インデックスの作成がサポートされています。これは、値の配カラムを格納し、単一のデータレコードに対して複数のインデックスレコードを持つことができる JSON カラムに定義されたセカンダリインデックスです。このようなインデックスでは、CAST(data->'$.zipcode' AS UNSIGNED ARRAY) などのキー部分定義が使用されます。複数値インデックスは、EXPLAIN の出力で表示できるように、適切なクエリーのために MySQL オプティマイザによって自動的に使用されます。

この作業の一環として、MySQL では、JSON ドキュメントを操作するための新しい関数 JSON_OVERLAPS() および新しい MEMBER OF() 演算子が追加され、さらに次のリストで説明するように、CAST() 関数が新しい ARRAY キーワードで拡張されます:
- JSON_OVERLAPS() では、2 つの JSON 文書が比較されます。共通のキーと値のペアまたは配列要素が含まれている場合、この関数は TRUE (1) を返し、それ以外の場合は FALSE (0) を返します。両方の値がスカラーの場合、関数は等価性の単純なテストを実行します。一方の引数が JSON 配列で、もう一方がスカラーの場合、スカラーは配列要素として扱われます。したがって、JSON_OVERLAPS() は JSON_CONTAINS() の補完として機能します。
- MEMBER OF() は、最初のオペランド (スカラーまたは JSON ドキュメント) が 2 番目のオペランドとして渡された JSON 配列のメンバーであるかどうかをテストし、メンバーである場合は TRUE (1)、そうでない場合は FALSE (0) を返します。オペランドの型変換は実行されません。
- CAST(expression AS type ARRAY) では、json_path の JSON ドキュメントにある JSON 配列を SQL 配列にキャストすることで、関数インデックスを作成できます。型指定子は、CAST() ですでにサポートされているものに限られます。ただし BINARY (サポートされていません) を除きます。 CAST() (および ARRAY キーワード) のこの使用方法は、InnoDB でのみサポートされ、複数値インデックスの作成にのみ使用できます。
例を含む複数値インデックスの詳細は、複数値インデックスを参照してください。セクション12.18.3「JSON 値を検索する関数」では、JSON_OVERLAPS() および MEMBER OF() に関する情報を使用例とともに提供します。
time_zone を使用したオプティマイザヒント. MySQL 8.0.17 では、SET_VAR によるオプティマイザヒントに time_zone セッション変数を使用可能です。
redo ログのアーカイブ. MySQL 8.0.17 では、InnoDB は redo ログのアーカイブをサポートしています。 redo ログレコードをコピーするバックアップユーティリティは、バックアップ操作の進行中に redo ログの生成に対応できない場合があり、その結果、それらのレコードが上書きされるために redo ログレコードが失われます。 redo ログアーカイブ機能は、redo ログレコードをアーカイブファイルに順次書き込むことで、この問題に対処します。バックアップユーティリティでは、必要に応じてアーカイブファイルから redo ログレコードをコピーできるため、データが失われる可能性を回避できます。詳細は、redo ログのアーカイブを参照してください。
クローンプラグイン. MySQL 8.0.17 の時点で、MySQL は、InnoDB データをローカルまたはリモートの MySQL サーバーインスタンスからクローニングできるクローンプラグインを提供します。ローカルクローニング操作では、MySQL インスタンスが実行されているのと同じサーバーまたはノードにクローンデータが格納されます。リモートクローニング操作では、クローニング操作が開始されたドナー MySQL サーバーインスタンスから受信者サーバーまたはノードに、ネットワーク経由でクローンデータが転送されます。

クローンプラグインはレプリケーションをサポートします。クローニング操作では、クローニングデータに加えて、ドナーからレプリケーション座標が抽出および転送され、受信者に適用されるため、グループレプリケーションメンバーおよびレプリカのプロビジョニングにクローンプラグインを使用できます。プロビジョニングにクローンプラグインを使用すると、多数のトランザクションをレプリケートするよりもはるかに高速かつ効率的になります。グループレプリケーションメンバーは、シードメンバーからグループデータを取得する最も効率的な方法をメンバーが自動的に選択できるように、代替のリカバリ方法としてクローンプラグインを使用するように構成することもできます。

詳細は、セクション5.6.7「クローンプラグイン」およびセクション18.4.3.2「分散リカバリのためのクローニング」を参照してください。
ハッシュ結合の最適化. MySQL 8.0.18 以降、結合内のテーブルの各ペアに少なくとも 1 つの等価結合条件が含まれ、結合条件にはインデックスが適用されない場合は常にハッシュ結合が使用されます。ハッシュ結合はインデックスを必要としませんが、単一テーブルの述語にのみ適用されるインデックスで使用できます。ほとんどの場合、ハッシュ結合はブロックネストループアルゴリズムより効率的です。ここに示すような結合は、次の方法で最適化できます:
```
Press CTRL+C to copy
 
SELECT *
    FROM t1
    JOIN t2
        ON t1.c1=t2.c1;

SELECT *
    FROM t1
    JOIN t2
        ON (t1.c1 = t2.c1 AND t1.c2 < t2.c2)
    JOIN t3
        ON (t2.c1 = t3.c1)
```
ハッシュ結合は、デカルト積 (結合条件が指定されていない場合) にも使用できます。

EXPLAIN FORMAT=TREE または EXPLAIN ANALYZE を使用して、ハッシュ結合の最適化が特定のクエリーに使用されているかどうかを確認できます。 (MySQL 8.0.20 以降では、FORMAT=TREE を省略して EXPLAIN を使用することもできます。)

ハッシュ結合で使用可能なメモリー量は、join_buffer_size の値によって制限されます。この量を超えるメモリーを必要とするハッシュ結合がディスク上で実行されます。ディスク上のハッシュ結合で使用できるディスクファイルの数は、open_files_limit によって制限されます。

MySQL 8.0.19 の時点では、MySQL 8.0.18 で導入された hash_join オプティマイザスイッチはサポートされなくなりました (hash_join=on は optimizer_switch の値の一部として表示されますが、設定しても効果はなくなります)。 HASH_JOIN および NO_HASH_JOIN オプティマイザヒントもサポートされなくなりました。スイッチとヒントの両方が非推奨になりました。将来の MySQL リリースで削除される予定です。 MySQL 8.0.18 以降では、NO_BNL オプティマイザスイッチを使用してハッシュ結合を無効にできます。

MySQL 8.0.20 以降では、ブロックのネステッドループは MySQL サーバーで使用されなくなり、クエリーに等価結合条件が含まれていない場合でも、ブロックのネステッドループが以前に使用された場合は常にハッシュ結合が使用されます。これは、内部非等価結合、準結合、アンチ結合、左外部結合および右外部結合に適用されます。 optimizer_switch システム変数、BNL および NO_BNL オプティマイザヒントに対する block_nested_loop フラグは引き続きサポートされますが、以降はハッシュ結合の使用のみが制御されます。また、内部結合と外部結合 (準結合とアンチ結合を含む) の両方でバッチキーアクセス (BKA) を使用できるようになりました。BKA では、結合バッファメモリーが増分的に割り当てられるため、個々のクエリーで実際には解決に必要のない大量のリソースを使用する必要はありません。内部結合の BKA は、MySQL 8.0.18 以降でのみサポートされています。

また、MySQL 8.0.20 は、以前のバージョンの MySQL で使用されていたエグゼキュータをイテレータエグゼキュータに置き換えます。この作業には、準結合として最適化されていない IN クエリーに対する WHERE value IN (SELECT column FROM table WHERE ...) 形式のクエリーを制御する古いインデックスサブクエリーエンジンの置換、および以前は古いエグゼキュータに依存していた同じ形式で実体化されたクエリーが含まれます。

詳細および例については、セクション8.2.1.4「ハッシュ結合の最適化」を参照してください。 Batched Key Access 結合も参照してください。
EXPLAIN ANALYZE ステートメント. 新しい形式の EXPLAIN ステートメント EXPLAIN ANALYZE が MySQL 8.0.18 に実装され、クエリーの処理に使用されるイテレータごとに SELECT ステートメントの実行に関する拡張情報が TREE 形式で提供され、見積りコストをクエリーの実際のコストと比較できるようになりました。この情報には、起動コスト、合計コスト、このイテレータによって返された行数および実行されたループ数が含まれます。

MySQL 8.0.21 以降では、このステートメントは FORMAT=TREE 指定子もサポートしています。サポートされている形式は TREE のみです。

詳しくはEXPLAIN ANALYZE による情報の取得,をご覧ください。
クエリーキャスト注入. 8.0.18 以降のバージョンでは、MySQL は、引数のデータ型と予想されるデータ型が一致しない式および条件内のクエリーアイテムツリーにキャスト操作を注入します。これはクエリー結果や実行速度には影響しませんが、以前のリリースの MySQL との下位互換性を維持しながら、クエリーを SQL 標準に準拠したものと同じように実行します。

このような暗黙的なキャストは、時間型 (DATE, DATETIME, TIMESTAMP, TIME) と数値型 (SMALLINT, TINYINT, MEDIUMINT, INT/INTEGER、BIGINT; DECIMAL / NUMERIC; FLOAT, DOUBLE, REAL; BIT) の間で実行されます。いずれかの標準数値比較演算子 (=, >=, >, <, <=, <> / !=、または <=>) を使用して実行されるものです。この場合、まだ DOUBLE ではない値はキャストされます。キャストインジェクションは、DATE または TIME の値と DATETIME の値の比較に対しても実行されるようになりました。引数は DATETIME として必要に応じてキャストされます。

MySQL 8.0.21 以降、このようなキャストは、文字列型を他の型と比較するときにも実行されます。キャストされる文字列型には、CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM および SET があります。文字列型の値を数値型または YEAR と比較する場合、文字列のキャストは DOUBLE になります。他の引数の型が FLOAT、DOUBLE または REAL でない場合は、DOUBLE にもキャストされます。文字列型を DATETIME または TIMESTAMP 値と比較する場合、文字列は DATETIME にキャストされ、文字列型を DATE と比較する場合、文字列は DATE にキャストされます。

次に示すように、EXPLAIN ANALYZE、EXPLAIN FORMAT=JSON または EXPLAIN FORMAT=TREE の出力を表示することで、特定のクエリーにキャストが注入されるタイミングを確認できます:
```
Press CTRL+C to copy
 
mysql> CREATE TABLE d (dt DATETIME, d DATE, t TIME);
Query OK, 0 rows affected (0.62 sec)

mysql> CREATE TABLE n (i INT, d DECIMAL, f FLOAT, dc DECIMAL);
Query OK, 0 rows affected (0.51 sec)

mysql> CREATE TABLE s (c CHAR(25), vc VARCHAR(25),
    ->     bn BINARY(50), vb VARBINARY(50), b BLOB, t TEXT,
    ->     e ENUM('a', 'b', 'c'), se SET('x' ,'y', 'z'));
Query OK, 0 rows affected (0.50 sec)

mysql> EXPLAIN FORMAT=TREE SELECT * from d JOIN n ON d.dt = n.i\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (cast(d.dt as double) = cast(n.i as double))
(cost=0.70 rows=1)
    -> Table scan on n  (cost=0.35 rows=1)
    -> Hash
        -> Table scan on d  (cost=0.35 rows=1)

mysql> EXPLAIN FORMAT=TREE SELECT * from s JOIN d ON d.dt = s.c\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (d.dt = cast(s.c as datetime(6)))  (cost=0.72 rows=1)
    -> Table scan on d  (cost=0.37 rows=1)
    -> Hash
        -> Table scan on s  (cost=0.35 rows=1)

1 row in set (0.01 sec)

mysql> EXPLAIN FORMAT=TREE SELECT * from n JOIN s ON n.d = s.c\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (cast(n.d as double) = cast(s.c as double))  (cost=0.70 rows=1)
    -> Table scan on s  (cost=0.35 rows=1)
    -> Hash
        -> Table scan on n  (cost=0.35 rows=1)

1 row in set (0.00 sec)
```
このようなキャストは、EXPLAIN [FORMAT=TRADITIONAL]を実行することでも確認できます。この場合、EXPLAIN ステートメントの実行後に SHOW WARNINGS を発行する必要もあります。
TIMESTAMP および DATETIME のタイムゾーンサポート. MySQL 8.0.19 の時点では、サーバーは日時 (TIMESTAMP および DATETIME) 値が挿入されたタイムゾーンオフセットを受け入れます。このオフセットは、time_zone システム変数の設定時に採用されたフォーマットと同じフォーマットを使用しますが、オフセットの時間部分が 10 未満で、'-00:00'が許可されていない場合に先行ゼロが必要になる点が異なります。タイムゾーンオフセットを含む日時リテラルの例には、'2019-12-11 10:40:30-05:00'、'2003-04-14 03:30:00+10:00'および'2020-01-01 15:35:45+05:30'があります。

日時値を選択する場合、タイムゾーンオフセットは表示されません。

タイムゾーンオフセットを組み込む日時リテラルは、プリペアドコンパイルされたステートメントのパラメータ値として使用できます。

この作業の一環として、time_zone システム変数の設定に使用される値も、-14:00 から +14:00 までの範囲に制限されるようになりました。 (MySQL タイムゾーンテーブルがロードされている場合は、time_zone に、'EST'、'Posix/Australia/Brisbane'、および'Europe/Stockholm'といった名前の値を割り当てることができます。タイムゾーンテーブルへの移入を参照してください)。

詳細および例は、セクション5.1.15「MySQL Server でのタイムゾーンのサポート」およびセクション11.2.2「DATE、DATETIME、および TIMESTAMP 型」を参照してください。
JSON スキーマの CHECK 制約の失敗に関する正確な情報. JSON_SCHEMA_VALID() を使用して CHECK 制約を指定する場合、MySQL 8.0.19 以降では、このような制約の失敗の理由に関する正確な情報が提供されます。

例および詳細は、JSON_SCHEMA_VALID() および CHECK 制約を参照してください。セクション13.1.20.6「CHECK 制約」も参照してください。
ON DUPLICATE KEY UPDATE を使用した行およびカラムのエイリアス. MySQL 8.0.19 以降では、エイリアスを使用して、挿入する行およびそのカラム (オプション) を参照できます。カラム a および b を含むテーブル t で、次の INSERT ステートメントを考えてみます:
```
Press CTRL+C to copy
 
INSERT INTO t SET a=9,b=5
    ON DUPLICATE KEY UPDATE a=VALUES(a)+VALUES(b);
```
新しい行にエイリアス new を使用し、場合によっては、この行のカラムにエイリアス m および n を使用すると、INSERT ステートメントを様々な方法でリライトできます。次に例をいくつか示します:
```
Press CTRL+C to copy
 
INSERT INTO t SET a=9,b=5 AS new
    ON DUPLICATE KEY UPDATE a=new.a+new.b;

INSERT INTO t VALUES(9,5) AS new
    ON DUPLICATE KEY UPDATE a=new.a+new.b;

INSERT INTO t SET a=9,b=5 AS new(m,n)
    ON DUPLICATE KEY UPDATE a=m+n;

INSERT INTO t VALUES(9,5) AS new(m,n)
    ON DUPLICATE KEY UPDATE a=m+n;
```
詳細および例については、セクション13.2.6.2「INSERT ... ON DUPLICATE KEY UPDATE ステートメント」を参照してください。
SQL 標準の明示的なテーブル句およびテーブル値コンストラクタ. SQL 標準に従って、テーブル値コンストラクタおよび明示的なテーブル句が追加されました。これらは、それぞれ TABLE ステートメントおよび VALUES ステートメントとして MySQL 8.0.19 に実装されます。

TABLE ステートメントの形式は TABLE table_name で、SELECT * FROM table_name と同等です。 ORDER BY 句および LIMIT 句 (後者はオプションで OFFSET で併用可) はサポートされますが、個々のテーブルのカラムを選択することはできません。 TABLE は、同等の SELECT ステートメントを使用できる場所であればどこでも使用できます。これには、JOIN、UNION、INSERT ... SELECT, REPLACE, CREATE TABLE ... SELECT ステートメントおよびサブクエリーが含まれます。例:
- TABLE t1 UNION TABLE t2 は SELECT * FROM t1 UNION SELECT * FROM t2 と同等です
- CREATE TABLE t2 TABLE t1 は CREATE TABLE t2 SELECT * FROM t1 と同等です
- SELECT a FROM t1 WHERE b > ANY (TABLE t2) は、SELECT a FROM t1 WHERE b > ANY (SELECT * FROM t2) と同等です。
VALUES は、INSERT、REPLACE または SELECT ステートメントにテーブルの値を指定するために使用でき、VALUES キーワードの後にカンマで区切られた一連の行コンストラクタ (ROW()) が続きます。たとえば、SQL 標準に準拠した INSERT INTO t1 VALUES ROW(1,2,3), ROW(4,5,6), ROW(7,8,9) というステートメントは、MySQL 固有の INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9) と同等です。テーブルと同じように、VALUES テーブルの値コンストラクタから選択することもできます (これには、テーブルのエイリアスを指定しなければならないことに注意)。これは他の SELECT と同じように使えます。JOIN、UNION およびサブクエリーを含みます。

TABLE および VALUES の詳細とその使用例は、このドキュメントの次のセクションを参照してください:
FORCE INDEX、IGNORE INDEX のオプティマイザヒント. MySQL 8.0 では、セクション8.9.4「インデックスヒント」で説明されている従来のインデックスヒントと同様に機能するインデックスレベルのオプティマイザヒントが導入されています。新しいヒントとそれに相当する FORCE INDEX または IGNORE INDEX のヒントを次に示します:
- GROUP_INDEX: FORCE INDEX FOR GROUP BY と同等
  
  NO_GROUP_INDEX: IGNORE INDEX FOR GROUP BY と同等
- JOIN_INDEX: FORCE INDEX FOR JOIN と同等
  
  NO_JOIN_INDEX: IGNORE INDEX FOR JOIN と同等
- ORDER_INDEX: FORCE INDEX FOR ORDER BY と同等
  
  NO_ORDER_INDEX: IGNORE INDEX FOR ORDER BY と同等
- INDEX: GROUP_INDEX に JOIN_INDEX と ORDER_INDEX を加えたものと同じです。修飾子のない FORCE INDEX と同等です
  
  NO_INDEX: NO_GROUP_INDEX に NO_JOIN_INDEX と NO_ORDER_INDEX を加えたものと同じです。修飾子のない IGNORE INDEX と同等です
たとえば、次の 2 つのクエリーは同等です。
```
Press CTRL+C to copy
 
SELECT a FROM t1 FORCE INDEX (i_a) FOR JOIN WHERE a=1 AND b=2;

SELECT /*+ JOIN_INDEX(t1 i_a) */ a FROM t1 WHERE a=1 AND b=2;
```
前述のオプティマイザヒントは、既存のインデックスレベルのオプティマイザヒントと同じ構文および使用方法の基本ルールに従います。

これらのオプティマイザヒントは、将来の MySQL リリースで非推奨になり、その後 MySQL から削除する予定の FORCE INDEX および IGNORE INDEX を置き換えることを目的としています。 USE INDEX に同等の単一のものは実装されません。かわりに、NO_INDEX, NO_JOIN_INDEX, NO_GROUP_INDEX または NO_ORDER_INDEX のいずれかを使用して同じ効果を得ることができます。

詳細および使用例は、インデックスレベルのオプティマイザヒントを参照してください。
JSON_VALUE() 関数. MySQL 8.0.21 には、JSON カラムのインデックス付けを簡略化するための新しい関数 JSON_VALUE() が実装されています。最も基本的な形式では、引数として JSON ドキュメントおよびそのドキュメント内の単一の値を指す JSON パスを取り、オプションで RETURNING キーワードを使用して戻り型を指定できます。 JSON_VALUE(json_doc, path RETURNING type) は次と同等です:
```
Press CTRL+C to copy
 
CAST(
    JSON_UNQUOTE( JSON_EXTRACT(json_doc, path) )
    AS type
);
```
JSON_TABLE() で採用されている場合と同様に、ON EMPTY、ON ERROR、またはその両方の句を指定することもできます。

JSON_VALUE() を使用して、次のように JSON カラムの式にインデックスを作成できます:
```
Press CTRL+C to copy
 
CREATE TABLE t1(
    j JSON,
    INDEX i1 ( (JSON_VALUE(j, '$.id' RETURNING UNSIGNED)) )
);

INSERT INTO t1 VALUES ROW('{"id": "123", "name": "shoes", "price": "49.95"}');
```
次に示すように、この式を使用するクエリーではインデックスを使用できます:
```
Press CTRL+C to copy
 
SELECT name, price FROM t1
    WHERE JSON_VALUE(j, '$.id' RETURNING UNSIGNED) = 123;
```
多くの場合、これは、JSON カラムから生成カラムを作成し、生成カラムにインデックスを作成するよりも簡単です。

詳細および例は、JSON_VALUE() の説明を参照してください。
ユーザーコメントとユーザー属性. MySQL 8.0.21 では、ユーザーアカウントの作成または更新時にユーザーコメントおよびユーザー属性を設定する機能が導入されています。ユーザーコメントは、CREATE USER ステートメントまたは ALTER USER ステートメントで使用される COMMENT 句に引数として渡される任意のテキストで構成されます。ユーザー属性は、これらのステートメントのいずれかで使用される ATTRIBUTE 句に引数として渡される JSON オブジェクトの形式のデータで構成されます。属性には、JSON オブジェクト表記法の有効なキーと値のペアを含めることができます。単一の CREATE USER ステートメントまたは ALTER USER ステートメントで使用できるのは、COMMENT または ATTRIBUTE のいずれかのみです。

ユーザーコメントとユーザー属性は JSON オブジェクトとして内部的に格納され、コメントテキストはキーとして comment を持つ要素の値として格納されます。この情報は、INFORMATION_SCHEMA.USER_ATTRIBUTES テーブルの ATTRIBUTE カラムから取得できます。JSON 形式であるため、MySQL JSON 関数および演算子を使用して内容を解析できます (セクション12.18「JSON 関数」を参照)。ユーザー属性に対する後続の変更は、JSON_MERGE_PATCH() 関数を使用する場合と同様に現在の値とマージされます。

例:
```
Press CTRL+C to copy
 
mysql> CREATE USER 'mary'@'localhost' COMMENT 'This is Mary Smith\'s account';
Query OK, 0 rows affected (0.33 sec)

mysql> ALTER USER 'mary'@'localhost'
    -≫     ATTRIBUTE '{"fname":"Mary", "lname":"Smith"}';
Query OK, 0 rows affected (0.14 sec)

mysql> ALTER USER 'mary'@'localhost'
    -≫     ATTRIBUTE '{"email":"mary.smith@example.com"}';
Query OK, 0 rows affected (0.12 sec)

mysql> SELECT
    ->    USER,
    ->    HOST,
    ->    ATTRIBUTE->>"$.fname" AS 'First Name',
    ->    ATTRIBUTE->>"$.lname" AS 'Last Name',
    ->    ATTRIBUTE->>"$.email" AS 'Email',
    ->    ATTRIBUTE->>"$.comment" AS 'Comment'
    -> FROM INFORMATION_SCHEMA.USER_ATTRIBUTES
    -> WHERE USER='mary' AND HOST='localhost'\G
*************************** 1. row ***************************
      USER: mary
      HOST: localhost
First Name: Mary
 Last Name: Smith
     Email: mary.smith@example.com
   Comment: This is Mary Smith's account
1 row in set (0.00 sec)
```
詳細および例は、セクション13.7.1.3「CREATE USER ステートメント」、セクション13.7.1.1「ALTER USER ステートメント」およびセクション26.46「INFORMATION_SCHEMA USER_ATTRIBUTES テーブル」を参照してください。
新しい optimizer_switch フラグ. MySQL 8.0.21 では、次のリストに示すように、optimizer_switch システム変数に 2 つの新しいフラグが追加されます:
- prefer_ordering_index フラグ
  
  デフォルトでは、MySQL は LIMIT 句を持つ ORDER BY または GROUP BY クエリーに対して順序付けされたインデックスを使用しようとします。オプティマイザは、この結果、実行速度が速くなると判断します。このようなクエリーに対して異なる最適化を選択する方が実際にパフォーマンスが向上する場合があるため、prefer_ordering_index フラグを off に設定することで、この最適化を無効にできるようになりました。
  
  このフラグのデフォルト値は on です。
- subquery_to_derived フラグ
  
  このフラグが on に設定されている場合、オプティマイザは適格なスカラーサブクエリーを導出テーブルの結合に変換します。たとえば、クエリー SELECT * FROM t1 WHERE t1.a > (SELECT COUNT(a) FROM t2) は SELECT t1.a FROM t1 JOIN ( SELECT COUNT(t2.a) AS c FROM t2 ) AS d WHERE t1.a > d.c としてリライトされます。
  
  この最適化は、SELECT, WHERE, JOIN 句または HAVING 句の一部であるサブクエリーに適用できます。1 つ以上の集計関数は含まれますが、GROUP BY 句は含まれません。相関関係はなく、非決定的関数は使用されません。
  
  最適化は、IN, NOT IN, EXISTS または NOT EXISTS の引数であり、GROUP BY を含まないテーブルサブクエリーにも適用できます。たとえば、クエリー SELECT * FROM t1 WHERE t1.b < 0 OR t1.a IN (SELECT t2.a + 1 FROM t2) は SELECT a, b FROM t1 LEFT JOIN (SELECT DISTINCT 1 AS e1, t2.a AS e2 FROM t2) d ON t1.a + 1 = d.e2 WHERE t1.b < 0 OR d.e1 IS NOT NULL としてリライトされます。
  
  この最適化は、ほとんどの場合に顕著なパフォーマンスの向上をもたらさないため、通常は無効になっています。フラグはデフォルトで off に設定されます。
詳細は、セクション8.9.2「切り替え可能な最適化」を参照してください。セクション8.2.1.19「LIMIT クエリーの最適化」、セクション8.2.2.1「準結合変換による IN および EXISTS サブクエリー述語の最適化」およびセクション8.2.2.4「マージまたは実体化を使用した導出テーブル、ビュー参照および共通テーブル式の最適化」も参照してください。
XML の拡張機能. MySQL 8.0.21 では、LOAD XML ステートメントで XML の CDATA セクションのインポートがサポートされるようになりました。
YEAR 型へのキャストがサポートされるようになりました. MySQL 8.0.22 以降、サーバーは YEAR へのキャストを許可します。 CAST() 関数と CONVERT() 関数の両方で、単一桁、2 桁および 4 桁の YEAR 値がサポートされています。 1 桁および 2 桁の値の場合、使用できる範囲は 0-99 です。 4 桁の値は 1901-2155 の範囲内である必要があります。 YEAR は、JSON_VALUE() 関数の戻り型としても使用できます。この関数は 4 桁の年のみをサポートします。

文字列、日時および浮動小数点値はすべて YEAR にキャストできます。 GEOMETRY 値の YEAR へのキャストはサポートされていません。

変換ルールを含む詳細は、CONVERT() 関数の説明を参照してください。
TIMESTAMP 値の UTC としての取得. MySQL 8.0.22 以降では、CAST(value AT TIME ZONE specifier AS DATETIME) を使用した、取得時のシステムタイムゾーンから UTC DATETIME への TIMESTAMP カラム値の変換がサポートされています。ここで、指定子は[INTERVAL] '+00:00'または'UTC'のいずれかです。キャストによって返される DATETIME 値の精度は、必要に応じて小数点以下 6 桁まで指定できます。 ARRAY キーワードは、この構成ではサポートされていません。

タイムゾーンオフセットを使用してテーブルに挿入された TIMESTAMP 値もサポートされます。 AT TIME ZONE の使用は、CONVERT() またはその他の MySQL 関数や構造体ではサポートされていません。

詳細および例は、CAST() 関数の説明を参照してください。
ダンプファイル出力の同期. MySQL 8.0.22 以降では、SELECT INTO DUMPFILE および SELECT INTO OUTFILE ステートメントによるファイルへの書込み時に定期的な同期がサポートされます。これを有効にするには、select_into_disk_sync システム変数を ON に設定します。書込みバッファのサイズは、select_into_buffer_size に設定された値によって決まります。デフォルトは 131072 (2 ¹⁷) バイトです。

また、ディスクへの同期後のオプションの遅延は、select_into_disk_sync_delay を使用して設定できます。デフォルトは遅延なし (0 ミリ秒) です。

詳細は、この項目で前述した変数の説明を参照してください。
ステートメントの準備の単一化. MySQL 8.0.22 の時点では、プリペアドステートメントは、実行されるたびに一度ではなく、最初に一度だけ準備されます。これは、PREPARE の実行時に行われます。これは、ストアドプロシージャ内のすべてのステートメントにも当てはまります。このステートメントは、ストアドプロシージャが最初に実行されたときに一度準備されます。

この変更の結果、プリペアドステートメントで使用される動的パラメータが解決される方法も、次に示す方法で変更されます:
- プリペアドステートメントのパラメータには、ステートメントの準備時にデータ型が割り当てられます。ステートメントが再準備されないかぎり、ステートメントの後続の実行ごとに型が保持されます。次を参照してください。
  
  準備されたステートメント内の特定のパラメータまたはユーザー変数に別のデータ型を使用して最初の実行後にステートメントを実行すると、ステートメントが再準備される可能性があります。このため、準備されたステートメントを再実行するときは、指定されたパラメータに同じデータ型を使用することをお薦めします。
- ウィンドウ関数を使用する次の構造体は、SQL 標準に合せるために受け入れられなくなりました:
  - NTILE(NULL)
  - NTH_VALUE(expr, NULL)
  - LEAD(expr, nn) および LAG(expr, nn)(nn は負数)
  これにより、SQL 標準への準拠が容易になります。詳細は、個々の関数の説明を参照してください。
- プリペアドステートメント内で参照されるユーザー変数のデータ型は、ステートメントの準備時に決定されるようになりました。この型は、ステートメントの後続の実行ごとに保持されます。
- ストアドプロシージャ内で実行されるステートメントによって参照されるユーザー変数のデータ型は、ステートメントの初回実行時に決定されるようになりました。この型は、格納されているストアドプロシージャの後続の起動でも保持されます。
- SELECT expr1, expr2, ... FROM table ORDER BY ? 形式のプリペアドステートメントを実行するときに、パラメータに整数値 N を渡すと、選択リストの N ^th 式による結果の順序付けが行われなくなります。ORDER BY constant で期待される通りには、結果が順序付けされなくなります。
プリペアドステートメントとして、またはストアドプロシージャ内で使用されるステートメントとして最初に一度だけ準備することにより、ステートメントのパフォーマンスが向上します。これは、繰返し準備の追加コストが削減されるためです。これにより、MySQL での多数の問題の原因となった準備構造の複数のロールバックを回避することもできます。

詳細は、セクション13.5.1「PREPARE ステートメント」を参照してください。
LEFT JOIN 処理としての RIGHT JOIN. MySQL 8.0.22 点では、サーバーは RIGHT JOIN のすべてのインスタンスを LEFT JOIN として内部的に処理することで、パース時に完全な変換が行われないいくつかの特別なケースを排除しました。
導出条件プッシュダウン最適化. MySQL 8.0.22 (以降) は、実体化導出テーブルを持つクエリーの導出条件プッシュダウンを実装します。 SELECT * FROM (SELECT i, j FROM t1) AS dt WHERE i > constant などのクエリーでは、多くの場合、外部 WHERE 条件を導出テーブルにプッシュできるようになりました (この場合、SELECT * FROM (SELECT i, j FROM t1 WHERE i > constant) AS dt になります)。

以前は、導出テーブルが実体化されてマージされていない場合、MySQL はテーブル全体を実体化し、WHERE 条件で行を修飾していました。導出条件プッシュダウン最適化を使用して WHERE 条件をサブクエリーに移動すると、多くの場合、処理が必要な行数が減り、クエリーの実行に必要な時間が短縮されます。

導出テーブルで集計関数またはウィンドウ関数が使用されていない場合は、外部 WHERE 条件を実体化導出テーブルに直接プッシュダウンできます。導出テーブルに GROUP BY があり、ウィンドウ関数を使用しない場合、外部 WHERE 条件を HAVING 条件として導出テーブルにプッシュダウンできます。導出テーブルがウィンドウ関数を使用し、外部 WHERE がウィンドウ関数の PARTITION 句で使用されるカラムを参照している場合は、WHERE 条件をプッシュダウンすることもできます。

導出条件プッシュダウンは、optimizer_switch システム変数 derived_condition_pushdown フラグで示されるように、デフォルトで有効になっています。 MySQL 8.0.22 で追加されたフラグは、デフォルトで on に設定されています。特定のクエリーの最適化を無効にするには、NO_DERIVED_CONDITION_PUSHDOWN オプティマイザヒント (こちらも MySQL 8.0.22 で追加) を使用できます。 derived_condition_pushdown が off に設定されているために最適化が無効になっている場合は、DERIVED_CONDITION_PUSHDOWN を使用して特定のクエリーに対して最適化を有効にできます。

導出条件プッシュダウン最適化は、UNION 句または LIMIT 句を含む導出テーブルには使用できません。また、サブクエリーを使用する条件自体はプッシュダウンできず、外部結合の内部テーブルでもある導出テーブルに WHERE 条件をプッシュダウンすることもできません。追加情報および例については、セクション8.2.2.5「導出条件プッシュダウン最適化」を参照してください。
MySQL 付与テーブルでの非ロック読み取り. MySQL 8.0.22 では、MySQL 付与テーブルに対する同時 DML 操作および DDL 操作を許可するために、MySQL 付与テーブルに対して以前に行ロックを取得した読取り操作は、非ロック読取りとして実行されます。

MySQL 付与テーブルで非ロック読み取りとして実行されるようになった操作には、次のものがあります:
- 任意のトランザクション分離レベルを使用して、結合リストおよびサブクエリー (SELECT ... FOR SHARE ステートメントを含む) を介して付与テーブルからデータを読み取る SELECT ステートメントおよびその他の読取り専用ステートメント。
- 任意のトランザクション分離レベルを使用して (結合リストまたはサブクエリーを介して) 付与テーブルからデータを読み取り、変更を伴わない DML 操作。
追加情報についてはテーブル同時実行性の付与を参照してください。

MySQL 8.0 で非推奨となった機能

次の機能は MySQL 8.0 では非推奨であり、将来のシリーズで削除される可能性があります。ほかのオプションがあれば、それを利用するためにアプリケーションを更新する必要があります。

上位の MySQL シリーズで削除された MySQL 8.0 で非推奨になった機能を使用するアプリケーションの場合、MySQL 8.0 ソースから上位シリーズのレプリカにレプリケートするとステートメントが失敗するか、ソースとレプリカに異なる影響を与える可能性があります。このような問題を回避するには、8.0 で非推奨になった機能を使用するアプリケーションを改訂して回避し、可能な場合は代替機能を使用する必要があります。

utf8mb3 文字セットは非推奨です。かわりに utf8mb4 を使用してください。
caching_sha2_password は MySQL 8.0 のデフォルトの認証プラグインであり、sha256_password 認証プラグインの機能のスーパーセットを提供するため、sha256_password は非推奨になりました。将来のバージョンの MySQL で削除される予定です。 sha256_password を使用して認証する MySQL アカウントは、かわりに caching_sha2_password を使用するように移行する必要があります。
validate_password プラグインは、コンポーネントインフラストラクチャを使う形式で再実装されました。プラグイン形式の validate_password は引き続き使用可能ですが、非推奨になりました。将来のバージョンの MySQL で削除される予定です。プラグインを使用する MySQL インストールでは、かわりにコンポーネントの使用に移行する必要があります。セクション6.4.3.3「パスワード検証コンポーネントへの移行」を参照してください。
ALTER TABLESPACE および DROP TABLESPACE ステートメントの ENGINE 句は非推奨になりました。
PAD_CHAR_TO_FULL_LENGTH SQL モードは非推奨です。
AUTO_INCREMENT のサポートは、FLOAT 型および DOUBLE 型のカラム (およびシノニム) では非推奨です。このようなカラムから AUTO_INCREMENT 属性を削除するか、整数型に変換することを検討してください。
UNSIGNED 属性は、FLOAT、DOUBLE および DECIMAL(およびシノニム) 型のカラムでは非推奨です。このようなカラムには、かわりに単純な CHECK 制約の使用を検討してください。
FLOAT および DOUBLE(およびシノニム) 型のカラムの桁数を指定するための FLOAT(M,D) および DOUBLE(M,D) 構文は、非標準 MySQL 拡張機能です。この構文は非推奨です。
ZEROFILL 属性は、整数データ型の表示幅属性と同様に、数値データ型では非推奨です。これらの属性の効果を生成する別の方法の使用を検討してください。たとえば、アプリケーションでは、LPAD() 関数を使用して、必要な幅まで数値をゼロ埋めたり、書式設定された数値を CHAR カラムに格納したりできます。
文字列データ型の場合、BINARY 属性は、カラム文字セット (またはカラム文字セットが指定されていない場合はテーブルのデフォルト文字セット) のバイナリ (_bin) 照合順序を指定するための短縮形である非標準の MySQL 拡張機能です。 MySQL 8.0 では、utf8mb4 文字セットに複数の_bin 照合順序があるため、この BINARY の非標準の使用はあいまいです。このため、BINARY 属性は非推奨になりました。将来のバージョンの MySQL ではサポートされなくなる予定です。かわりに、明示的な_bin 照合を使用するようにアプリケーションを調整する必要があります。

BINARY を使用してデータ型または文字セットを指定する方法は変わりません。
標準の SQL AND、OR および NOT 演算子のシノニムである非標準の C 形式の &&、||および ! 演算子は、それぞれ非推奨になりました。非標準演算子を使用するアプリケーションは、標準演算子を使用するように調整する必要があります。

注記

PIPES_AS_CONCAT SQL モードが有効になっていないかぎり、||の使用は非推奨です。その場合、||は SQL 標準の文字列連結演算子を示します。
JSON_MERGE() 関数は非推奨です。かわりに JSON_MERGE_PRESERVE() を使用してください。
SQL_CALC_FOUND_ROWS クエリー修飾子および付随する FOUND_ROWS() 関数は非推奨です。代替戦略の詳細は、FOUND_ROWS() の説明を参照してください。
CREATE TEMPORARY TABLE での TABLESPACE = innodb_file_per_table 句および TABLESPACE = innodb_temporary 句のサポートは、MySQL 8.0.13 で非推奨になりました。
SELECT ステートメントの場合、FROM の後に INTO 句を使用することはできますが、SELECT の最後には使用できません (MySQL 8.0.20 の時点では非推奨です)。ステートメントの最後に INTO を配置することをお薦めします。

UNION ステートメントの場合、INTO を含む次の 2 つのバリアントは、MySQL 8.0.20 で非推奨になりました:
- クエリー式の後続のクエリーブロックでは、FROM の前に INTO を使用します。
- クエリー式のカッコで囲まれた後続ブロックでは、FROM に対する相対位置に関係なく、INTO を使用します。
セクション13.2.10.1「SELECT ... INTO ステートメント」およびセクション13.2.10.3「UNION 句」を参照してください。
FLUSH HOSTS は、MySQL 8.0.23 の時点では非推奨です。代わりに、パフォーマンススキーマ host_cache テーブルを切り捨てます:
```
Press CTRL+C to copy
 
TRUNCATE TABLE performance_schema.host_cache;
```
TRUNCATE TABLE 操作には、テーブルに対する DROP 権限が必要です。
mysql システムスキーマ内のシステムテーブルおよび他のスキーマ内のオブジェクトをアップグレードする機能が MySQL サーバーに移動されたため、mysql_upgrade クライアントは非推奨になりました。セクション2.11.3「MySQL のアップグレードプロセスの内容」を参照してください。
--no-dd-upgrade サーバーオプションは非推奨です。データディクショナリおよびサーバーのアップグレード動作をより細かく制御できる --upgrade オプションに置き換えられています。
データディレクトリが作成され、MySQL のバージョン番号の格納に使用される mysql_upgrade_info ファイルは非推奨になりました。将来のバージョンの MySQL で削除される予定です。
relay_log_info_file システム変数および --master-info-file オプションは非推奨になりました。以前は、これらは relay_log_info_repository=FILE および master_info_repository=FILE の設定時にリレーログ情報ログおよびソース情報ログの名前を指定するために使用されていましたが、これらの設定は非推奨になりました。リレーログ情報ログおよびソース情報ログのファイルの使用は、MySQL 8.0 のデフォルトであるクラッシュセーフレプリカテーブルに置き換えられました。
max_length_for_sort_data システム変数は、オプティマイザの変更によって廃止され、効果がないため、非推奨になりました。
サーバーへの接続を圧縮するためのこれらのレガシーパラメータは非推奨です: --compress クライアントのコマンド行オプション、mysql_options() C API 関数の MYSQL_OPT_COMPRESS オプション、slave_compressed_protocol システム変数。かわりに使用するパラメータの詳細は、セクション4.2.8「接続圧縮制御」を参照してください。
MYSQL_PWD 環境変数を使用した MySQL パスワードの指定は非推奨です。
VALUES() を使用した INSERT ... ON DUPLICATE KEY UPDATE の新しい行値へのアクセスは、MySQL 8.0.20 では非推奨です。かわりに、新しい行とカラムにエイリアスを使用します。
JSON_TABLE() の呼び出し時に ON EMPTY の前に ON ERROR を指定することは SQL 標準に反しているため、この構文は MySQL で非推奨になりました。 MySQL 8.0.20 以降では、試行するたびにサーバーによって警告が出力されます。単一の JSON_TABLE() 起動でこれらの句の両方を指定する場合は、ON EMPTY が最初に使用されていることを確認してください。
インデックス接頭辞を持つカラムは、テーブルパーティション化キーの一部としてサポートされるいません。以前は、パーティションテーブルの作成、変更またはアップグレード時に許可されていましたが、テーブルパーティション化関数によって除外され、これがサーバーによって警告を発することはありませんでした。以前許可されていた動作は非推奨になり、将来のバージョンの MySQL で削除される (パーティション化キーでこのようなカラムを使用すると、CREATE TABLE または ALTER TABLE ステートメントが拒否される) 可能性があります。

MySQL 8.0.21 では、インデックス接頭辞を使用するカラムがパーティション化キーの一部として指定されるたびに、そのようなカラムごとに警告が生成されます。提案されたパーティション化キーのすべてのカラムにインデックス接頭辞があるために CREATE TABLE または ALTER TABLE ステートメントが拒否されると、結果のエラーに拒否の正確な理由が示されるようになりました。どちらの場合も、これには、空の PARTITION BY KEY() 句を使用して、パーティション化関数で使用されるカラムがテーブルの主キーのカラムとして暗黙的に定義されるケースが含まれます。

詳細および例については、カラムインデックス接頭辞はキーパーティション化ではサポートされていませんを参照してください。
InnoDB memcached プラグインは、MySQL 8.0.22 の時点では非推奨です。将来のバージョンの MySQL ではサポートされなくなる予定です。

MySQL 8.0 で削除された機能

次の項目は廃止され、MySQL 8.0 で削除されました。ほかのオプションがあれば、それを利用するためにアプリケーションを更新する必要があります。

MySQL 8.0 で削除された機能を使用する MySQL 5.7 アプリケーションの場合、MySQL 5.7 ソースから MySQL 8.0 レプリカにレプリケートするとステートメントが失敗するか、ソースとレプリカに異なる影響を与える可能性があります。このような問題を回避するには、MySQL 8.0 で削除された機能を使用するアプリケーションを改訂して回避し、可能な場合は代替機能を使用する必要があります。

innodb_locks_unsafe_for_binlog システム変数が削除されました。 READ COMMITTED 分離レベルは、同様の機能を提供します。
MySQL 8.0.0 で導入された information_schema_stats 変数は、MySQL 8.0.3 で information_schema_stats_expiry によって削除および置換されました。

information_schema_stats_expiry は、キャッシュされた INFORMATION_SCHEMA テーブル統計の有効期限設定を定義します。詳細は、セクション8.2.3「INFORMATION_SCHEMA クエリーの最適化」を参照してください。

廃止された InnoDB システムテーブルに関連するコードは、MySQL 8.0.3 で削除されました。 InnoDB システムテーブルに基づく INFORMATION_SCHEMA ビューは、データディクショナリテーブルの内部システムビューに置き換えられました。影響を受ける InnoDB INFORMATION_SCHEMA ビューの名前が変更されました:

表 1.1 名前が変更された InnoDB 情報スキーマビュー

旧名称	新規名
`INNODB_SYS_COLUMNS`	`INNODB_COLUMNS`
`INNODB_SYS_DATAFILES`	`INNODB_DATAFILES`
`INNODB_SYS_FIELDS`	`INNODB_FIELDS`
`INNODB_SYS_FOREIGN`	`INNODB_FOREIGN`
`INNODB_SYS_FOREIGN_COLS`	`INNODB_FOREIGN_COLS`
`INNODB_SYS_INDEXES`	`INNODB_INDEXES`
`INNODB_SYS_TABLES`	`INNODB_TABLES`
`INNODB_SYS_TABLESPACES`	`INNODB_TABLESPACES`
`INNODB_SYS_TABLESTATS`	`INNODB_TABLESTATS`
`INNODB_SYS_VIRTUAL`	`INNODB_VIRTUAL`

MySQL 8.0.3 以上にアップグレードした後、以前の InnoDB INFORMATION_SCHEMA ビュー名を参照するスクリプトを更新します。

アカウント管理に関連する次の機能が削除されました:
- GRANT を使用したユーザーの作成。かわりに、CREATE USER を使用してください。この変更により、NO_AUTO_CREATE_USER SQL モードが GRANT ステートメントで不要になったため、これも削除されました。オプションファイルの sql_mode オプションにこの値の記述があることによって mysqld の起動ができない場合は、サーバーログにエラーが書き込まれるようになります。
- GRANT を使用した権限割当て以外のアカウントプロパティの変更。これには、認証、SSL およびリソース制限のプロパティが含まれます。かわりに、CREATE USER を使用してアカウント作成時にこのようなプロパティを設定するか、後で ALTER USER を使用して変更します。
- CREATE USER および GRANT の IDENTIFIED BY PASSWORD 'auth_string'構文。かわりに、IDENTIFIED WITH auth_plugin AS 'auth_string' for CREATE USER and ALTER USER を使用します。ここで、'auth_string'値は指定されたプラグインと互換性のある形式です。
  
  また、IDENTIFIED BY PASSWORD 構文が削除されたため、log_builtin_as_identified_by_password システム変数は不要になり、削除されました。
- PASSWORD() 関数。なお、PASSWORD() の削除とは、SET PASSWORD ... = PASSWORD('auth_string') 構文が使用できなくなったことを意味します。
- old_passwords システム変数。
クエリーキャッシュが削除されました。削除には次の項目が含まれます:
- FLUSH QUERY CACHE および RESET QUERY CACHE ステートメント。
- これらのシステム変数: query_cache_limit, query_cache_min_res_unit, query_cache_size, query_cache_type, query_cache_wlock_invalidate。
- これらのステータス変数: Qcache_free_blocks, Qcache_free_memory, Qcache_hits, Qcache_inserts, Qcache_lowmem_prunes, Qcache_not_cached, Qcache_queries_in_cache, Qcache_total_blocks。
- これらのスレッド状態: checking privileges on cached query, checking query cache for query, invalidating query cache entries, sending cached result to client, storing result in query cache, Waiting for query cache lock。
- SQL_CACHE SELECT 修飾子。
これらの非推奨のクエリーキャッシュアイテムは非推奨のままですが、効果はありません。将来の MySQL リリースで削除される予定です:
- SQL_NO_CACHE SELECT 修飾子。
- ndb_cache_check_time システム変数。
have_query_cache システム変数は非推奨のままであり、常に NO の値を持ちます。将来の MySQL リリースで削除される予定です。
データディクショナリはデータベースオブジェクトに関する情報を提供するため、サーバーはデータディレクトリ内のディレクトリ名をチェックしてデータベースを検索しなくなります。その結果、--ignore-db-dir オプションと ignore_db_dirs システム変数は無意味となり、削除されました。
メタデータログとも呼ばれる DDL ログが削除されました。 MySQL 8.0.3 以降、この機能はデータディクショナリの innodb_ddl_log テーブルによって処理されます。 DDL ログの表示を参照してください。
tx_isolation および tx_read_only システム変数が削除されました。かわりに transaction_isolation および transaction_read_only を使用してください。
.frm ファイルが廃止されたため、sync_frm システム変数は削除されました。
secure_auth システム変数および --secure-auth クライアントオプションが削除されました。 mysql_options() C API 関数の MYSQL_SECURE_AUTH オプションが削除されました。
multi_range_count システム変数が削除されます。
log_warnings システム変数および --log-warnings サーバーオプションが削除されました。かわりに log_error_verbosity システム変数を使用してください。
sql_log_bin システム変数のグローバルスコープが削除されました。sql_log_bin にはセッションスコープのみとなり、@@GLOBAL.sql_log_bin へのアクセスに依存するアプリケーションは修正する必要があります。
metadata_locks_cache_size および metadata_locks_hash_instances システム変数が削除されます。
未使用の date_format, datetime_format, time_format および max_tmp_tables システム変数が削除されます。
これらの非推奨の互換性 SQL モードは削除されました: DB2, MAXDB, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS。これらを sql_mode システム変数に割り当てたり、mysqldump --compatible オプションの許可された値として使用したりすることはできなくなりました。

MAXDB の削除とは、CREATE TABLE または ALTER TABLE の TIMESTAMP データ型が TIMESTAMP として扱われ、DATETIME として扱われなくなることを意味します。
GROUP BY 句の非推奨の ASC 修飾子または DESC 修飾子は削除されます。以前に GROUP BY ソートに依存していたクエリーでは、以前の MySQL バージョンとは異なる結果が生成される場合があります。特定のソート順序を生成するには、ORDER BY 句を指定します。
EXPLAIN ステートメントの EXTENDED および PARTITIONS キーワードは削除されました。これらのキーワードは、その効果が常に有効になっているため不要です。
次の暗号化関連項目が削除されます:
- ENCODE() および DECODE() の機能。
- ENCRYPT() 関数。
- DES_ENCRYPT() 関数、DES_DECRYPT() 関数、--des-key-file オプション、have_crypt システム変数、FLUSH ステートメントの DES_KEY_FILE オプション、および HAVE_CRYPT CMake オプション。
削除された暗号化機能のかわり: ENCRYPT() の場合は、一方向ハッシュのかわりに SHA2() を使用することを検討してください。その他の場合は、かわりに AES_ENCRYPT() および AES_DECRYPT() の使用を検討してください。
MySQL 5.7 では、複数の名前で使用可能ないくつかの空間関数は、空間関数ネームスペースの一貫性を高めるために非推奨になりました。各空間関数名が ST_(正確な操作を実行する場合) または MBR(最小境界矩形に基づいて操作を実行する場合) で始まるという目標です。 MySQL 8.0 では、非推奨となった関数は削除され、対応する ST_および MBR 関数のみが残されます:
- これらの関数は、MBR 名を優先して削除されます: Contains(), Disjoint(), Equals(), Intersects(), Overlaps(), Within()。
- これらの関数は、ST_名を優先して削除されます: Area(), AsBinary(), AsText(), AsWKB(), AsWKT(), Buffer(), Centroid(), ConvexHull(), Crosses(), Dimension(), Distance(), EndPoint(), Envelope(), ExteriorRing(), GeomCollFromText(), GeomCollFromWKB(), GeomFromText(), GeomFromWKB(), GeometryCollectionFromText(), GeometryCollectionFromWKB(), GeometryFromText(), GeometryFromWKB(), GeometryN(), GeometryType(), InteriorRingN(), IsClosed(), IsEmpty(), IsSimple(), LineFromText(), LineFromWKB(), LineStringFromText(), LineStringFromWKB(), MLineFromText(), MLineFromWKB(), MPointFromText(), MPointFromWKB(), MPolyFromText(), MPolyFromWKB(), MultiLineStringFromText(), MultiLineStringFromWKB(), MultiPointFromText(), MultiPointFromWKB(), MultiPolygonFromText(), MultiPolygonFromWKB(), NumGeometries(), NumInteriorRings(), NumPoints(), PointFromText(), PointFromWKB(), PointN(), PolyFromText(), PolyFromWKB(), PolygonFromText(), PolygonFromWKB(), SRID(), StartPoint(), Touches(), X(), Y()。
- GLength() は、ST_Length() を優先して削除されます。
セクション12.17.4「WKB 値からジオメトリ値を作成する関数」で説明されている関数は、WKB 文字列またはジオメトリ引数を以前に受け入れていました。ジオメトリ引数は許可されなくなり、エラーが発生します。ジオメトリ引数を使用しないでクエリーを移行するためのガイドラインについては、そのセクションを参照してください。
パーサーは、SQL ステートメントで\N を NULL のシノニムとして処理しなくなりました。かわりに NULL を使用してください。

この変更は、NULL が\N によって引き続き表される LOAD DATA または SELECT ... INTO OUTFILE で実行されるテキストファイルのインポートまたはエクスポート操作には影響しません。セクション13.2.7「LOAD DATA ステートメント」を参照してください。
PROCEDURE ANALYSE() 構文が削除されました。
クライアント側の --ssl および --ssl-verify-server-cert オプションが削除されました。 --ssl=1 または --enable-ssl のかわりに --ssl-mode=REQUIRED を使用します。 --ssl=0、--skip-ssl または --disable-ssl のかわりに --ssl-mode=DISABLED を使用します。 --ssl-verify-server-cert オプションのかわりに --ssl-mode=VERIFY_IDENTITY を使用します。 (サーバー側の --ssl オプションは変更されません。)

C API の場合、mysql_options() の MYSQL_OPT_SSL_ENFORCE および MYSQL_OPT_SSL_VERIFY_SERVER_CERT オプションはクライアント側の --ssl および --ssl-verify-server-cert オプションに対応し、削除されます。かわりに、SSL_MODE_REQUIRED または SSL_MODE_VERIFY_IDENTITY のオプション値を指定して MYSQL_OPT_SSL_MODE を使用します。
--temp-pool サーバーオプションが削除されました。
ignore_builtin_innodb システム変数が削除されます。
サーバーは、特殊文字を含む pre-MySQL 5.1 データベース名を、#mysql50#接頭辞が追加された 5.1 形式に変換しなくなりました。これらの変換は実行されなくなったため、mysqlcheck の --fix-db-names および --fix-table-names オプション、ALTER DATABASE ステートメントの UPGRADE DATA DIRECTORY NAME 句および Com_alter_db_upgrade ステータス変数は削除されます。

アップグレードは、あるメジャーバージョンから別のメジャーバージョン (5.0 から 5.1、5.1 から 5.5 など) へのアップグレードでのみサポートされるため、古い 5.0 データベース名を現在のバージョンの MySQL に変換する必要はほとんどありません。回避策として、より新しいリリースにアップグレードする前に、MySQL 5.0 インストールを MySQL 5.1 にアップグレードします。
mysql_install_db プログラムが MySQL ディストリビューションから削除されました。データディレクトリの初期化は、かわりに --initialize または --initialize-insecure オプションを指定して mysqld を起動することで実行する必要があります。さらに、mysql_install_db で使用された mysqld の --bootstrap オプションが削除され、mysql_install_db のインストール場所を制御する INSTALL_SCRIPTDIR CMake オプションが削除されました。
汎用パーティション化ハンドラが MySQL サーバーから削除されました。特定のテーブルのパーティション化をサポートするには、テーブルに使用されるストレージエンジンが独自の (「native」) パーティショニングハンドラを提供する必要があります。 --partition および --skip-partition オプションは MySQL Server から削除され、パーティション関連のエントリは SHOW PLUGINS の出力または INFORMATION_SCHEMA.PLUGINS テーブルに表示されなくなります。

現在、2 つの MySQL ストレージエンジンがネイティブのパーティショニングサポートを提供しています: InnoDB および NDB。これらのうち、MySQL 8.0 でサポートされているのは InnoDB のみです。他のストレージエンジンを使用して MySQL 8.0 でパーティションテーブルを作成しようとすると、失敗します。

アップグレードの影響. InnoDB (MyISAM など) 以外のストレージエンジンを使用した MySQL 5.7 以前から MySQL 8.0 へのパーティションテーブルの直接アップグレードはサポートされていません。このようなテーブルを処理するには、次の 2 つのオプションがあります:
- ALTER TABLE ... REMOVE PARTITIONING を使用してテーブルのパーティション化を削除します。
- ALTER TABLE ... ENGINE=INNODB を使用して、テーブルに使用されるストレージエンジンを InnoDB に変更します。
サーバーを MySQL 8.0 にアップグレードする前に、パーティション化された InnoDB 以外のテーブルごとに、前述の 2 つ以上の操作を実行する必要があります。そうしないと、アップグレード後にそのようなテーブルを使用できません。

パーティション化がサポートされていない記憶域エンジンを使用してパーティション化されたテーブルを作成するテーブル作成ステートメントがエラー ( ER_CHECK_NOT_IMPLEMENTED ) で失敗するようになりました。そのため、MySQL 8.0 にインポートする古いバージョンの MySQL から出力されたダンプファイル (mysqldump によって出力されたものなど) に記載された、パーティション化されたテーブルを作成するステートメントが、ネイティブパーティショニングハンドラを持たない MyISAM などの記憶域エンジンを指定していないことを確認する必要があります。これを行うには、次のいずれかを実行します:
- InnoDB 以外の STORAGE ENGINE オプションの値を使用する CREATE TABLE ステートメントからパーティション化への参照を削除します。
- ストレージエンジンを InnoDB として指定するか、デフォルトで InnoDB をテーブルストレージエンジンとして使用できるようにします。
詳細は、セクション24.6.2「ストレージエンジンに関連するパーティショニング制限」を参照してください。
システム変数およびステータス変数の情報は、INFORMATION_SCHEMA で管理されなくなりました。これらのテーブルは削除されます: GLOBAL_VARIABLES, SESSION_VARIABLES, GLOBAL_STATUS, SESSION_STATUS。かわりに、対応する「パフォーマンススキーマ」テーブルを使用してください。セクション27.12.14「パフォーマンススキーマシステム変数テーブル」およびセクション27.12.15「パフォーマンススキーマのステータス変数のテーブル」を参照してください。さらに、show_compatibility_56 システム変数が削除されました。これは、INFORMATION_SCHEMA テーブルのシステム変数およびステータス変数の情報が「パフォーマンススキーマ」テーブルに移動され、不要になった移行期間に使用されました。これらのステータス変数は削除されます: Slave_heartbeat_period, Slave_last_heartbeat, Slave_received_heartbeats, Slave_retried_transactions, Slave_running。提供される情報は、「パフォーマンススキーマ」のテーブルにあります。Migrating to Performance Schema System and Status Variable Tables を参照してください。
パフォーマンススキーマ setup_timers テーブルは、performance_timers テーブルの TICK 行と同様に削除されました。
libmysqld 埋込みサーバーライブラリが次とともに削除されます:
- mysql_options() MYSQL_OPT_GUESS_CONNECTION, MYSQL_OPT_USE_EMBEDDED_CONNECTION, MYSQL_OPT_USE_REMOTE_CONNECTION および MYSQL_SET_CLIENT_IP のオプション
- mysql_config --libmysqld-libs、--embedded-libs および --embedded のオプション
- CMake WITH_EMBEDDED_SERVER、WITH_EMBEDDED_SHARED_LIBRARY および INSTALL_SECURE_FILE_PRIV_EMBEDDEDDIR のオプション
- (ドキュメント化されていない)mysql --server-arg オプション
- mysqltest --embedded-server、--server-arg および --server-file のオプション
- mysqltest_embedded および mysql_client_test_embedded のテストプログラム
mysql_plugin ユーティリティが削除されました。代替方法には、--plugin-load または --plugin-load-add オプションを使用したサーバー起動時、または INSTALL PLUGIN ステートメントを使用した実行時のプラグインのロードが含まれます。
resolveip ユーティリティが削除されます。かわりに、nslookup、host または dig を使用できます。
resolve_stack_dump ユーティリティが削除されます。正式な MySQL ビルドからのスタックトレースは常にシンボル化されるため、resolve_stack_dump を使用する必要はありません。

次のサーバーエラーコードは使用されておらず、削除されています。これらのエラーのいずれかをテストするアプリケーションを更新する必要があります。

Press CTRL+C to copy
 
ER_BINLOG_READ_EVENT_CHECKSUM_FAILURE
ER_BINLOG_ROW_RBR_TO_SBR
ER_BINLOG_ROW_WRONG_TABLE_DEF
ER_CANT_ACTIVATE_LOG
ER_CANT_CHANGE_GTID_NEXT_IN_TRANSACTION
ER_CANT_CREATE_FEDERATED_TABLE
ER_CANT_CREATE_SROUTINE
ER_CANT_DELETE_FILE
ER_CANT_GET_WD
ER_CANT_SET_GTID_PURGED_WHEN_GTID_MODE_IS_OFF
ER_CANT_SET_WD
ER_CANT_WRITE_LOCK_LOG_TABLE
ER_CREATE_DB_WITH_READ_LOCK
ER_CYCLIC_REFERENCE
ER_DB_DROP_DELETE
ER_DELAYED_NOT_SUPPORTED
ER_DIFF_GROUPS_PROC
ER_DISK_FULL
ER_DROP_DB_WITH_READ_LOCK
ER_DROP_USER
ER_DUMP_NOT_IMPLEMENTED
ER_ERROR_DURING_CHECKPOINT
ER_ERROR_ON_CLOSE
ER_EVENTS_DB_ERROR
ER_EVENT_CANNOT_DELETE
ER_EVENT_CANT_ALTER
ER_EVENT_COMPILE_ERROR
ER_EVENT_DATA_TOO_LONG
ER_EVENT_DROP_FAILED
ER_EVENT_MODIFY_QUEUE_ERROR
ER_EVENT_NEITHER_M_EXPR_NOR_M_AT
ER_EVENT_OPEN_TABLE_FAILED
ER_EVENT_STORE_FAILED
ER_EXEC_STMT_WITH_OPEN_CURSOR
ER_FAILED_ROUTINE_BREAK_BINLOG
ER_FLUSH_MASTER_BINLOG_CLOSED
ER_FORM_NOT_FOUND
ER_FOUND_GTID_EVENT_WHEN_GTID_MODE_IS_OFF__UNUSED
ER_FRM_UNKNOWN_TYPE
ER_GOT_SIGNAL
ER_GRANT_PLUGIN_USER_EXISTS
ER_GTID_MODE_REQUIRES_BINLOG
ER_GTID_NEXT_IS_NOT_IN_GTID_NEXT_LIST
ER_HASHCHK
ER_INDEX_REBUILD
ER_INNODB_NO_FT_USES_PARSER
ER_LIST_OF_FIELDS_ONLY_IN_HASH_ERROR
ER_LOAD_DATA_INVALID_COLUMN_UNUSED
ER_LOGGING_PROHIBIT_CHANGING_OF
ER_MALFORMED_DEFINER
ER_MASTER_KEY_ROTATION_ERROR_BY_SE
ER_NDB_CANT_SWITCH_BINLOG_FORMAT
ER_NEVER_USED
ER_NISAMCHK
ER_NO_CONST_EXPR_IN_RANGE_OR_LIST_ERROR
ER_NO_FILE_MAPPING
ER_NO_GROUP_FOR_PROC
ER_NO_RAID_COMPILED
ER_NO_SUCH_KEY_VALUE
ER_NO_SUCH_PARTITION__UNUSED
ER_OBSOLETE_CANNOT_LOAD_FROM_TABLE
ER_OBSOLETE_COL_COUNT_DOESNT_MATCH_CORRUPTED
ER_ORDER_WITH_PROC
ER_PARTITION_SUBPARTITION_ERROR
ER_PARTITION_SUBPART_MIX_ERROR
ER_PART_STATE_ERROR
ER_PASSWD_LENGTH
ER_QUERY_ON_MASTER
ER_RBR_NOT_AVAILABLE
ER_SKIPPING_LOGGED_TRANSACTION
ER_SLAVE_CHANNEL_DELETE
ER_SLAVE_MULTIPLE_CHANNELS_HOST_PORT
ER_SLAVE_MUST_STOP
ER_SLAVE_WAS_NOT_RUNNING
ER_SLAVE_WAS_RUNNING
ER_SP_GOTO_IN_HNDLR
ER_SP_PROC_TABLE_CORRUPT
ER_SQL_MODE_NO_EFFECT
ER_SR_INVALID_CREATION_CTX
ER_TABLE_NEEDS_UPG_PART
ER_TOO_MUCH_AUTO_TIMESTAMP_COLS
ER_UNEXPECTED_EOF
ER_UNION_TABLES_IN_DIFFERENT_DIR
ER_UNSUPPORTED_BY_REPLICATION_THREAD
ER_UNUSED1
ER_UNUSED2
ER_UNUSED3
ER_UNUSED4
ER_UNUSED5
ER_UNUSED6
ER_VIEW_SELECT_DERIVED_UNUSED
ER_WRONG_MAGIC
ER_WSAS_FAILED

非推奨の INFORMATION_SCHEMA INNODB_LOCKS および INNODB_LOCK_WAITS テーブルは削除されます。代わりに、パフォーマンススキーマ data_locks および data_lock_waits テーブルを使用してください。

注記

MySQL 5.7 では、INNODB_LOCKS テーブルの LOCK_TABLE カラムと sys スキーマ innodb_lock_waits および x$innodb_lock_waits ビューの locked_table カラムには、スキーマ/テーブル名の値が結合されています。 MySQL 8.0 では、data_locks テーブルおよび sys スキーマビューに個別のスキーマ名およびテーブル名のカラムが含まれます。セクション28.4.3.9「innodb_lock_waits および x$innodb_lock_waits のビュー」を参照してください。
InnoDB では、圧縮一時テーブルはサポートされなくなりました。 innodb_strict_mode が有効な場合 (デフォルト)、ROW_FORMAT=COMPRESSED または KEY_BLOCK_SIZE が指定されていると、CREATE TEMPORARY TABLE はエラーを返します。 innodb_strict_mode が無効な場合は、警告が発行され、圧縮されていない行形式を使用して一時テーブルが作成されます。
InnoDB では、MySQL データディレクトリ外にテーブルスペースデータファイルを作成する際に、.isl ファイル (InnoDB シンボリックリンクファイル) は作成されなくなりました。 innodb_directories オプションでは、データディレクトリ外で作成されたテーブルスペースファイルの検索がサポートされるようになりました。

この変更により、.isl ファイルを手動で変更してサーバーがオフラインのときにリモートテーブルスペースを移動することはサポートされなくなりました。リモートテーブルスペースファイルの移動は、innodb_directories オプションでサポートされるようになりました。セクション15.6.3.6「サーバーがオフラインのときのテーブルスペースファイルの移動」を参照してください。
次の InnoDB ファイル形式変数が削除されました:
- innodb_file_format
- innodb_file_format_check
- innodb_file_format_max
- innodb_large_prefix
MySQL 5.1 で以前のバージョンの InnoDB と互換性のあるテーブルを作成するには、ファイル形式変数が必要でした。 MySQL 5.1 が製品ライフサイクルの最後に到達したため、これらのオプションは不要になりました。

FILE_FORMAT カラムが INNODB_TABLES テーブルおよび INNODB_TABLESPACES「情報スキーマ」テーブルから削除されました。
XA トランザクションでの双方向コミットのサポートを可能にする innodb_support_xa システム変数が削除されました。 XA トランザクションでの双方向コミットの InnoDB サポートは、常に有効です。
DTrace のサポートが削除されました。
JSON_APPEND() 関数が削除されました。かわりに JSON_ARRAY_APPEND() を使用してください。
共有 InnoDB テーブルスペースへのテーブルパーティションの配置のサポートは、MySQL 8.0.13 で削除されました。共有テーブルスペースには、InnoDB システムテーブルスペースおよび一般テーブルスペースが含まれます。共有テーブルスペースのパーティションの識別および file-per-table テーブルスペースへの移動の詳細は、セクション2.11.5「アップグレード用のインストールの準備」を参照してください。
SET 以外のステートメントでのユーザー変数の設定のサポートは、MySQL 8.0.13 で非推奨になりました。この機能は、MySQL 9.0 で削除されることがあります。
--ndb perror オプションが削除されました。かわりに ndb_perror ユーティリティを使用してください。
innodb_undo_logs 変数が削除されました。 innodb_rollback_segments 変数は同じ機能を実行するため、かわりに使用する必要があります。
Innodb_available_undo_logs ステータス変数が削除されました。テーブルスペースごとに使用可能なロールバックセグメントの数は、SHOW VARIABLES LIKE 'innodb_rollback_segments';を使用して取得できます
MySQL 8.0.14 では、以前に非推奨となった innodb_undo_tablespaces 変数は構成できなくなりました。詳細は、セクション15.6.3.4「undo テーブルスペース」を参照してください。
ALTER TABLE ... UPGRADE PARTITIONING ステートメントのサポートは削除されました。
MySQL 8.0.16 では、internal_tmp_disk_storage_engine システム変数のサポートが削除されました。ディスク上の内部一時テーブルでは、常に InnoDB ストレージエンジンが使用されるようになりました。詳細は、オンディスク内部一時テーブルのストレージエンジンを参照してください。
DISABLE_SHARED CMake オプションは未使用であり、削除されました。

PREV HOME UP NEXT