データディクショナリが有効な MySQL サーバーの使用には、データディクショナリがないサーバーと比較して、いくつかの操作上の違いがあります:
-
以前は、
innodb_read_only
システム変数を有効にすると、InnoDB
ストレージエンジンのテーブルの作成および削除のみができなくなりました。 MySQL 8.0 の時点では、innodb_read_only
を有効にすると、すべてのストレージエンジンでこれらの操作が防止されます。 ストレージエンジンのテーブルの作成および削除操作では、mysql
システムデータベース内のデータディクショナリテーブルが変更されますが、これらのテーブルはInnoDB
ストレージエンジンを使用するため、innodb_read_only
が有効になっている場合は変更できません。 データディクショナリテーブルの変更を必要とする他のテーブル操作にも、同じ原則が適用されます。 例:データディクショナリに格納されているテーブル統計が更新されるため、
ANALYZE TABLE
は失敗します。データディクショナリに格納されているストレージエンジンの指定が更新されるため、
ALTER TABLE
は失敗します。tbl_name
ENGINE=engine_name
注記innodb_read_only
を有効にすると、mysql
システムデータベースのデータディクショナリ以外のテーブルにも重要な影響があります。 詳細は、セクション15.14「InnoDB の起動オプションおよびシステム変数」 のinnodb_read_only
の説明を参照してください 以前は、
mysql
システムデータベース内のテーブルは DML ステートメントおよび DDL ステートメントから参照できました。 MySQL 8.0 では、データディクショナリテーブルは非表示であり、直接変更またはクエリーできません。 ただし、ほとんどの場合、かわりにクエリーすることができる対応するINFORMATION_SCHEMA
テーブルがあります。 これにより、アプリケーションで使用する安定したINFORMATION_SCHEMA
インタフェースを維持しながら、基礎となるデータディクショナリテーブルをサーバー開発の進行中に変更できます。-
MySQL 8.0 の
INFORMATION_SCHEMA
テーブルはデータディクショナリに密接に関連付けられているため、いくつかの使用方法が異なります:以前は、
INFORMATION_SCHEMA
はSTATISTICS
およびTABLES
テーブルのテーブル統計をクエリーして、ストレージエンジンから直接統計を取得していました。 MySQL 8.0 では、キャッシュされたテーブルの統計がデフォルトで使用されます。information_schema_stats_expiry
システム変数は、キャッシュされたテーブルの統計が期限切れになるまでの期間を定義します。 デフォルトは 86400 秒 (24 時間) です。 (特定のテーブルのキャッシュされた値をいつでも更新するには、ANALYZE TABLE
を使用します。) キャッシュされた統計がない場合、または統計が期限切れになっている場合は、テーブル統計カラムのクエリー時にストレージエンジンから統計が取得されます。 常に最新の統計をストレージエンジンから直接取得するには、information_schema_stats_expiry
を0
に設定します。 詳細は、セクション8.2.3「INFORMATION_SCHEMA クエリーの最適化」を参照してください。いくつかの
INFORMATION_SCHEMA
テーブルはデータディクショナリテーブルのビューであり、オプティマイザはこれらの基礎となるテーブルでインデックスを使用できます。 したがって、オプティマイザの選択に応じて、INFORMATION_SCHEMA
クエリーの結果の行順序が以前の結果と異なる場合があります。 クエリー結果に特定の行順序付け特性が必要な場合は、ORDER BY
句を含めます。-
INFORMATION_SCHEMA
テーブルに対するクエリーでは、以前の MySQL シリーズとは異なる大文字と小文字でカラム名が返される場合があります。 アプリケーションでは、大/小文字を区別しない方法で結果セットのカラム名をテストする必要があります。 実行できない場合は、必要な文字のカラム名を返す選択リストでカラムのエイリアスを使用します。 例:SELECT TABLE_SCHEMA AS table_schema, TABLE_NAME AS table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'users';
mysqldump および mysqlpump は、コマンドラインで明示的に指定されていても、
INFORMATION_SCHEMA
データベースをダンプしなくなりました。CREATE TABLE
では、dst_tbl
LIKEsrc_tbl
src_tbl
が実テーブルである必要があり、データディクショナリテーブルのビューであるINFORMATION_SCHEMA
テーブルである場合は失敗します。-
以前は、
INFORMATION_SCHEMA
テーブルから選択されたカラムの結果セットヘッダーでは、クエリーで指定された大/小文字が使用されていました。 このクエリーでは、table_name
のヘッダーを含む結果セットが生成されます:SELECT table_name FROM INFORMATION_SCHEMA.TABLES;
MySQL 8.0 では、これらのヘッダーは大文字になります。前述のクエリーでは、
TABLE_NAME
のヘッダーを含む結果セットが生成されます。 必要に応じて、カラムのエイリアスを使用して別の大文字と小文字を実現できます。 例:SELECT table_name AS 'table_name' FROM INFORMATION_SCHEMA.TABLES;
-
データディレクトリは、mysqldump および mysqlpump が
mysql
システムデータベースから情報をダンプする方法に影響します:以前は、
mysql
システムデータベース内のすべてのテーブルをダンプできました。 MySQL 8.0 の時点では、mysqldump および mysqlpump はそのデータベース内のデータディクショナリ以外のテーブルのみをダンプします。以前は、
--routines
および--events
オプションは、--all-databases
オプションの使用時にストアドルーチンおよびイベントを含める必要はありませんでした: ダンプにはmysql
システムデータベースが含まれていたため、ストアドルーチンおよびイベント定義を含むproc
およびevent
テーブルも含まれていました。 MySQL 8.0 では、event
テーブルおよびproc
テーブルは使用されません。 対応するオブジェクトの定義はデータディクショナリテーブルに格納されますが、これらのテーブルはダンプされません。--all-databases
を使用して作成されたダンプにストアドルーチンおよびイベントを含めるには、--routines
および--events
オプションを明示的に使用します。以前は、
--routines
オプションにproc
テーブルに対するSELECT
権限が必要でした。 MySQL 8.0 では、このテーブルは使用されません。かわりに、--routines
にはグローバルSELECT
権限が必要です。以前は、
proc
およびevent
テーブルをダンプすることで、ストアドルーチンおよびイベント定義をそれらの作成および変更タイムスタンプとともにダンプできました。 MySQL 8.0 では、これらのテーブルは使用されないため、タイムスタンプをダンプすることはできません。
以前は、不正な文字を含むストアドルーチンを作成すると、警告が生成されました。 MySQL 8.0 では、これはエラーです。