MySQL 8.0 リファレンスマニュアル
MySQL 8.0 リファレンスマニュアル  /  ...  /  NDB Cluster の SQL 構文に準拠していません

23.1.7.1 NDB Cluster の SQL 構文に準拠していません

次のリストに示すように、特定の MySQL 機能に関連する SQL ステートメントの中には、NDB テーブルで使用したときにエラーを生成するものがあります。

  • 一時テーブル.  一時テーブルはサポートされません。 NDB ストレージエンジンを使用する一時テーブルを作成しようとしたり、NDB を使用するように既存の一時テーブルを変更しようとしたりすると、失敗して次のエラーが発生します:Table storage engine 'ndbcluster' does not support the create option 'TEMPORARY'.

  • NDB テーブルのインデックスとキー.  「NDB Cluster」テーブルのキーおよびインデックスには、次の制限事項があります:

    • カラム幅.  3072 バイトを超える幅の NDB テーブルカラムに対するインデックスを作成しようとすると、成功しますが、インデックスに実際に使用されるのは最初の 3072 バイトだけです。 このような場合は、警告 Specified key was too long; max key length is 3072 bytes が発行され、SHOW CREATE TABLE ステートメントではインデックスの長さが 3072 と表示されます。

    • TEXT および BLOB カラム.  TEXT または BLOB データ型のどちらかを使用する NDB テーブルカラムに対するインデックスは作成できません。

    • FULLTEXT インデックス.  NDB ストレージエンジンは、MyISAM および InnoDB テーブルでのみ可能な FULLTEXT インデックスをサポートしていません。

      ただし、NDB テーブルの VARCHAR カラムに対するインデックスは作成できます。

    • USING HASH キーと NULL.  一意キーおよび主キーで NULL 可能カラムを使用すると、これらのカラムを使用するクエリーは完全なテーブルスキャンとして処理されます。 この問題を回避するには、カラムを NOT NULL にするか、USING HASH オプションを指定せずにインデックスを再作成します。

    • プリフィクス.  プリフィクスインデックスはありません。インデックスはカラム全体にのみ付けることができます。 (NDB のカラムインデックスのサイズは、このセクションで前述したように、カラムの幅 (バイト単位) と常に同じ (最大 3072 バイトまで) です。 追加情報については、セクション23.1.7.6「NDB Cluster でサポートされない機能または欠落している機能」を参照してください。)

    • BIT カラム.  BIT カラムを主キー、一意キー、またはインデックスにすることはできません。また、複合の主キー、一意キー、またはインデックスの一部にすることもできません。

    • AUTO_INCREMENT カラム.  ほかの MySQL ストレージエンジンと同様に、NDB ストレージエンジンはテーブルあたり最大 1 つの AUTO_INCREMENT カラムを処理できます。 ただし、明示的な主キーを持たない NDB テーブルの場合は、AUTO_INCREMENT カラムが自動的に定義され、「「非表示」」主キーとして使用されます。 このため、明示的な AUTO_INCREMENT カラムを持つテーブルは、PRIMARY KEY オプションを同時に使用してカラムを宣言しないかぎり定義できません。 テーブルの主キーでない AUTO_INCREMENT カラムを持つテーブルを作成しようとして、NDB ストレージエンジンを使用すると、失敗してエラーが発生します。

  • 外部キーに関する制限.  NDB 8.0 での外部キー制約のサポートは、InnoDB で提供されるものと同等ですが、次の制限事項があります:

    • 外部キーとして参照されるすべてのカラムは、それがテーブルの主キーでない場合、明示的な一意キーを必要とします。

    • 参照先が親テーブルの主キーである場合、ON UPDATE CASCADE はサポートされません。

      これは、主キーの更新が古い行 (古い主キーを含む) の削除と新しい行 (新しい主キーを持つ) の挿入として実装されているためです。 これは NDB カーネルには表示されないため、これらの 2 つの行は同じであると表示されるため、この更新をカスケードする必要があることを知る方法はありません。

    • NDB 8.0.16 の時点: TEXT 型または BLOB 型のカラムが子テーブルに含まれている場合、ON DELETE CASCADE はサポートされません。 (Bug #89511、Bug #27484882)

    • SET DEFAULT はサポートされません。 (InnoDB でもサポートされません。)

    • NO ACTION キーワードは受け入れられますが、RESTRICT として扱われます。 MySQL 8.0 では、標準の SQL キーワードである NO ACTION がデフォルトです。 (InnoDB でも同じです。)

    • NDB Cluster の以前のバージョンでは、別のテーブル内のインデックスを参照する外部キーを持つテーブルを作成するとき、適切なエラーが常に内部的に返されなかったために、インデックス内のカラムの順序が一致しなかった場合でも、外部キーを作成できるように見えることがありました。 この問題を部分的に修正すると、ほとんどの場合に内部的に使用されるエラーが改善されましたが、親インデックスが一意インデックスである場合でも、この状況が発生する可能性があります。 (Bug #18094360)

    詳細は、セクション13.1.20.5「FOREIGN KEY の制約」およびセクション1.7.3.2「FOREIGN KEY の制約」を参照してください。

  • NDB Cluster およびジオメトリデータタイプ.  NDB テーブルでは、ジオメトリデータ型 (WKT および WKB) がサポートされます。 ただし、空間インデックスはサポートされません。

  • 文字セットとバイナリログファイル.  現在、ndb_apply_status および ndb_binlog_index テーブルは latin1 (ASCII) 文字セットを使用して作成されています。 バイナリログの名前はこのテーブルに記録されるため、ラテン語以外の文字を使用する名前が付けられたバイナリログファイルはこれらのテーブルで正しく参照されません。 これは既知の問題であり、現在修正中です。 (Bug #50226)

    この問題を回避するには、バイナリログファイルの名前を付けるときや、--basedir、--log-bin、または --log-bin-index オプションを設定するときに、Latin-1 文字のみを使用してください。

  • ユーザー定義のパーティション化を使用した「NDB の作成」テーブル.  NDB Cluster でのユーザー定義パーティショニングに対する のサポートは、[LINEAR] KEY パーティショニングに制限されています。 CREATE TABLE ステートメントで ENGINE=NDB または ENGINE=NDBCLUSTER とともにほかのパーティショニングタイプを使用すると、エラーが発生します。

    この制限はオーバーライドできますが、本番設定での使用はサポートされていません。 詳細は、ユーザー定義のパーティション分割と NDB ストレージエンジン (NDB Cluster)を参照してください。

    デフォルトのパーティション化スキーム.  「すべての NDB Cluster」テーブルは、デフォルトでは、テーブル主キーをパーティション化キーとして使用して KEY によってパーティション化されます。 テーブルに明示的に設定された主キーがない場合は、代わりに NDB ストレージエンジンによって自動的に作成された「隠し」主キーが使用されます。 これらおよび関連する問題の追加情報については、セクション24.2.5「KEY パーティショニング」を参照してください。

    ユーザーパーティション化された NDBCLUSTER テーブルが次の 2 つの要件のどちらかまたは両方を満たさない原因となる CREATE TABLE および ALTER TABLE ステートメントは許可されず、失敗してエラーが発生します。

    1. テーブルに明示的な主キーが存在する必要があります。

    2. テーブルのパーティショニング式に指定されたすべてのカラムが主キーの一部である必要があります。

    例外.  空のカラムリストを使用して (つまり、PARTITION BY [LINEAR] KEY() を使用して) ユーザーパーティション化された NDBCLUSTER テーブルを作成する場合は、明示的な主キーは必要ありません。

    NDBCLUSTER テーブルの最大パーティション数.  ユーザー定義のパーティション化を使用したときに NDBCLUSTER テーブルに定義できるパーティションの最大数は、ノードグループあたり 8 個です。 (NDB Cluster ノードグループの詳細は、セクション23.1.2「NDB Cluster ノード、ノードグループ、フラグメントレプリカ、およびパーティション」 を参照してください。

    DROP PARTITION の未サポート.  ALTER TABLE ... DROP PARTITION を使用して NDB テーブルからパーティションを削除することはできません。 ALTER TABLE に対するその他のパーティション化拡張機能 -ADD PARTITION、REORGANIZE PARTITION、および COALESCE PARTITION は NDB テーブルでサポートされますが、コピーを使用するため、最適化されません。 セクション24.3.1「RANGE および LIST パーティションの管理」およびセクション13.1.9「ALTER TABLE ステートメント」を参照してください。

  • 行ベースのレプリケーション.  NDB Cluster で行ベースレプリケーションを使用する場合、バイナリロギングを無効にすることはできません。 つまり、NDB ストレージエンジンは sql_log_bin の値を無視します。

  • JSON データ型.  MySQL JSON データ型は、NDB 8.0 で提供される mysqld 内の NDB テーブルでサポートされます。

    NDB テーブルには、最大 3 つの JSON カラムを含めることができます。

    NDB API には、単に BLOB データとして表示される JSON データを操作するための特別なプロビジョニングはありません。 JSON としてのデータの処理は、アプリケーションで実行する必要があります。


関連キーワード: 　NDB, テーブル, ndbinfo, ndb, カラム, インデックス, ノード, サポート, 作成, データ
PREV   HOME   UP   NEXT