データディクショナリ.  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 では、リソースグループの作成および管理がサポートされるようになり、グループで使用可能なリソースに従ってスレッドが実行されるように、サーバー内で実行されているスレッドを特定のグループに割り当てることができます。 グループ属性を使用すると、そのリソースを制御して、グループ内のスレッドによるリソース消費を有効にしたり制限したりすることができます。 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 の拡張機能が追加されました。

文字セットのサポート.  デフォルトの文字セットが latin1 から utf8mb4 に変更されました。 utf8mb4 文字セットには、MySQL の Unicode で使用可能な最初の日本語固有の照合である utf8mb4_ja_0900_as_cs を含む、いくつかの新しい照合順序があります。 詳細は、セクション10.10.1「Unicode 文字セット」を参照してください。

JSON の拡張機能.  MySQL JSON 機能が次のように拡張または追加されました:

データ型のサポート.  MySQL では、データ型指定でのデフォルト値としての式の使用がサポートされるようになりました。 これには、以前はデフォルト値を割り当てることができなかった BLOB, TEXT, GEOMETRY および JSON データ型のデフォルト値としての式の使用が含まれます。 詳細は、セクション11.6「データ型デフォルト値」を参照してください。

オプティマイザ.  次のオプティマイザ拡張機能が追加されました:

共通テーブル式.  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 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 プラグインは 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 ドキュメントを返します。 次のステートメントは、これらの両方の関数に適用されます:

詳細および例については、セクション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 キーワードで拡張されます:

例を含む複数値インデックスの詳細は、複数値インデックス を参照してください。セクション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 つの等価結合条件が含まれ、結合条件にはインデックスが適用されない場合は常にハッシュ結合が使用されます。 ハッシュ結合はインデックスを必要としませんが、単一テーブルの述語にのみ適用されるインデックスで使用できます。 ほとんどの場合、ハッシュ結合はブロックネストループアルゴリズムより効率的です。 ここに示すような結合は、次の方法で最適化できます:

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 の出力を表示することで、特定のクエリーにキャストが注入されるタイミングを確認できます:

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 ステートメントを考えてみます:

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

新しい行にエイリアス new を使用し、場合によっては、この行のカラムにエイリアス m および n を使用すると、INSERT ステートメントを様々な方法でリライトできます。次に例をいくつか示します:

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 ステートメントおよびサブクエリーが含まれます。 例:

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 のヒントを次に示します:

たとえば、次の 2 つのクエリーは同等です。

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) は次と同等です:

CAST(
    JSON_UNQUOTE( JSON_EXTRACT(json_doc, path) )
    AS type
);

JSON_TABLE() で採用されている場合と同様に、ON EMPTY、ON ERROR、またはその両方の句を指定することもできます。

JSON_VALUE() を使用して、次のように JSON カラムの式にインデックスを作成できます:

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"}');

次に示すように、この式を使用するクエリーではインデックスを使用できます:

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() 関数を使用する場合と同様に現在の値とマージされます。

例:

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 つの新しいフラグが追加されます:

詳細は、セクション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 の実行時に行われます。 これは、ストアドプロシージャ内のすべてのステートメントにも当てはまります。このステートメントは、ストアドプロシージャが最初に実行されたときに一度準備されます。

この変更の結果、プリペアドステートメントで使用される動的パラメータが解決される方法も、次に示す方法で変更されます:

プリペアドステートメントとして、またはストアドプロシージャ内で使用されるステートメントとして最初に一度だけ準備することにより、ステートメントのパフォーマンスが向上します。これは、繰返し準備の追加コストが削減されるためです。 これにより、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 付与テーブルで非ロック読み取りとして実行されるようになった操作には、次のものがあります:

追加情報については テーブル同時実行性の付与を参照してください。

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 形式の &&、||および ! 演算子は、それぞれ非推奨になりました。 非標準演算子を使用するアプリケーションは、標準演算子を使用するように調整する必要があります。

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 で非推奨になりました:

セクション13.2.10.1「SELECT ... INTO ステートメント」およびセクション13.2.10.3「UNION 句」を参照してください。

FLUSH HOSTS は、MySQL 8.0.23 の時点では非推奨です。 代わりに、パフォーマンススキーマ host_cache テーブルを切り捨てます:

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 ではサポートされなくなる予定です。

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 ビューの名前が変更されました:

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

アカウント管理に関連する次の機能が削除されました:

クエリーキャッシュが削除されました。 削除には次の項目が含まれます:

これらの非推奨のクエリーキャッシュアイテムは非推奨のままですが、効果はありません。将来の MySQL リリースで削除される予定です:

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 キーワードは削除されました。 これらのキーワードは、その効果が常に有効になっているため不要です。

次の暗号化関連項目が削除されます:

削除された暗号化機能のかわり: ENCRYPT() の場合は、一方向ハッシュのかわりに SHA2() を使用することを検討してください。 その他の場合は、かわりに AES_ENCRYPT() および AES_DECRYPT() の使用を検討してください。

MySQL 5.7 では、複数の名前で使用可能ないくつかの空間関数は、空間関数ネームスペースの一貫性を高めるために非推奨になりました。各空間関数名が ST_(正確な操作を実行する場合) または MBR(最小境界矩形に基づいて操作を実行する場合) で始まるという目標です。 MySQL 8.0 では、非推奨となった関数は削除され、対応する ST_および MBR 関数のみが残されます:

セクション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 つのオプションがあります:

サーバーを MySQL 8.0 にアップグレードする前に、パーティション化された InnoDB 以外のテーブルごとに、前述の 2 つ以上の操作を実行する必要があります。 そうしないと、アップグレード後にそのようなテーブルを使用できません。

パーティション化がサポートされていない記憶域エンジンを使用してパーティション化されたテーブルを作成するテーブル作成ステートメントがエラー ( ER_CHECK_NOT_IMPLEMENTED ) で失敗するようになりました。そのため、MySQL 8.0 にインポートする古いバージョンの MySQL から出力されたダンプファイル (mysqldump によって出力されたものなど) に記載された、パーティション化されたテーブルを作成するステートメントが、ネイティブパーティショニングハンドラを持たない MyISAM などの記憶域エンジンを指定していないことを確認する必要があります。 これを行うには、次のいずれかを実行します:

詳細は、セクション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_plugin ユーティリティが削除されました。 代替方法には、--plugin-load または --plugin-load-add オプションを使用したサーバー起動時、または INSTALL PLUGIN ステートメントを使用した実行時のプラグインのロードが含まれます。

resolveip ユーティリティが削除されます。かわりに、nslookup、host または dig を使用できます。

resolve_stack_dump ユーティリティが削除されます。 正式な MySQL ビルドからのスタックトレースは常にシンボル化されるため、resolve_stack_dump を使用する必要はありません。

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

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 テーブルを使用してください。

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 ファイル形式変数が削除されました:

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 オプションは未使用であり、削除されました。