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

14.7 データディクショナリの使用方法の違い

データディクショナリが有効な 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 LIKE src_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 では、これはエラーです。