次のリストに示すように、特定の MySQL 機能に関連する SQL ステートメントの中には、NDB
テーブルで使用したときにエラーを生成するものがあります。
一時テーブル 一時テーブルはサポートされません。
NDB
ストレージエンジンを使用する一時テーブルを作成しようとしたり、NDB
を使用するように既存の一時テーブルを変更しようとしたりすると、失敗して次のエラーが発生します:Table storage engine 'ndbcluster' does not support the create option 'TEMPORARY'.-
NDB テーブルのインデックスとキー MySQL 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
ストレージエンジンは、FULLTEXT
インデックスをサポートしません。これは、MyISAM
および (MySQL 5.6.4 以降の)InnoDB
テーブルでのみ可能です。ただし、
NDB
テーブルのVARCHAR
カラムに対するインデックスは作成できます。 USING HASH キーと NULL 一意キーおよび主キーで NULL 可能カラムを使用すると、これらのカラムを使用するクエリーは完全なテーブルスキャンとして処理されます。この問題を回避するには、カラムを
NOT NULL
にするか、USING HASH
オプションを指定せずにインデックスを再作成します。プリフィクス プリフィクスインデックスはありません。インデックスはカラム全体にのみ付けることができます。(
NDB
のカラムインデックスのサイズは、このセクションで前述したように、カラムの幅 (バイト単位) と常に同じ (最大 3072 バイトまで) です。追加情報については、セクション18.1.6.6「MySQL Cluster の未サポート機能または欠落している機能」を参照してください。)BIT カラム
BIT
カラムを主キー、一意キー、またはインデックスにすることはできません。また、複合の主キー、一意キー、またはインデックスの一部にすることもできません。AUTO_INCREMENT カラム ほかの MySQL ストレージエンジンと同様に、
NDB
ストレージエンジンはテーブルあたり最大 1 つのAUTO_INCREMENT
カラムを処理できます。ただし、明示的な主キーがないクラスタテーブルの場合は、AUTO_INCREMENT
カラムが自動的に定義され、「隠し」主キーとして使用されます。このため、明示的なAUTO_INCREMENT
カラムを持つテーブルは、PRIMARY KEY
オプションを同時に使用してカラムを宣言しないかぎり定義できません。テーブルの主キーでないAUTO_INCREMENT
カラムを持つテーブルを作成しようとして、NDB
ストレージエンジンを使用すると、失敗してエラーが発生します。
-
外部キーに関する制限 MySQL Cluster NDB 7.3 での外部キー制約のサポートは、
InnoDB
によるサポートと同等ですが、次の制限があります。外部キーとして参照されるすべてのカラムは、それがテーブルの主キーでない場合、明示的な一意キーを必要とします。
参照先が親テーブルの主キーである場合、
ON UPDATE CASCADE
はサポートされません。SET DEFAULT
はサポートされません。(InnoDB
でもサポートされません。)NO ACTION
キーワードは受け入れられますが、RESCRICT
として扱われます。(InnoDB
でも同じです。)MySQL Cluster NDB 7.3.5 以前のバージョンでは、別のテーブルのインデックスを参照する外部キーを含むテーブルを作成したときに、インデックス内のカラムの順序が一致しなくても内部で適切なエラーが返されないことがあったため、外部キーを作成できるように見える場合がありました。MySQL Cluster NDB 7.3.5 ではこの問題が部分的に修正され、内部で使用されるエラーがほとんどの場合に機能するように改善されましたが、親インデックスが一意のインデックスである場合は、まだこの状況が発生する可能性があります。(Bug #18094360)
詳細は、セクション13.1.17.2「外部キー制約の使用」およびセクション1.7.3.2「FOREIGN KEY の制約」を参照してください。
MySQL Cluster とジオメトリデータ型
NDB
テーブルでは、ジオメトリデータ型 (WKT
およびWKB
) がサポートされます。ただし、空間インデックスはサポートされません。-
文字セットとバイナリログファイル 現在、
ndb_apply_status
およびndb_binlog_index
テーブルはlatin1
(ASCII) 文字セットを使用して作成されています。バイナリログの名前はこのテーブルに記録されるため、ラテン語以外の文字を使用する名前が付けられたバイナリログファイルはこれらのテーブルで正しく参照されません。これは既知の問題であり、現在修正中です。(Bug #50226)この問題を回避するには、バイナリログファイルの名前を付けるときや、
--basedir
、--log-bin
、または--log-bin-index
オプションを設定するときに、Latin-1 文字のみを使用してください。 -
ユーザー定義のパーティション化を使用した NDBCLUSTER テーブルの作成 MySQL Cluster でのユーザー定義のパーティション化のサポートは、[
LINEAR
]KEY
のパーティション化に限定されます。CREATE TABLE
ステートメントでENGINE=NDB
またはENGINE=NDBCLUSTER
とともにほかのパーティショニングタイプを使用すると、エラーが発生します。デフォルトのパーティション化スキーム すべての MySQL Cluster テーブルは、デフォルトではテーブルの主キーをパーティション化キーとして使用して
KEY
によってパーティション化されます。テーブルに明示的に設定された主キーがない場合は、代わりにNDB
ストレージエンジンによって自動的に作成された「隠し」主キーが使用されます。これらおよび関連する問題の追加情報については、セクション19.2.5「KEY パーティショニング」を参照してください。ユーザーパーティション化された
NDBCLUSTER
テーブルが次の 2 つの要件のどちらかまたは両方を満たさない原因となるCREATE TABLE
およびALTER TABLE
ステートメントは許可されず、失敗してエラーが発生します。テーブルに明示的な主キーが存在する必要があります。
テーブルのパーティショニング式に指定されたすべてのカラムが主キーの一部である必要があります。
例外 空のカラムリストを使用して (つまり、
PARTITION BY [LINEAR] KEY()
を使用して) ユーザーパーティション化されたNDBCLUSTER
テーブルを作成する場合は、明示的な主キーは必要ありません。NDBCLUSTER テーブルの最大パーティション数 ユーザー定義のパーティション化を使用したときに
NDBCLUSTER
テーブルに定義できるパーティションの最大数は、ノードグループあたり 8 個です。(MySQL Cluster ノードグループの詳細は、セクション18.1.2「MySQL Cluster のノード、ノードグループ、レプリカ、およびパーティション」を参照してください。DROP PARTITION の未サポート
ALTER TABLE ... DROP PARTITION
を使用してNDB
テーブルからパーティションを削除することはできません。クラスタテーブルではALTER TABLE
に対する別のパーティション化拡張機能 (ADD PARTITION
、REORGANIZE PARTITION
、およびCOALESCE PARTITION
) がサポートされますが、コピーが使用されるため、最適化されません。セクション19.3.1「RANGE および LIST パーティションの管理」およびセクション13.1.7「ALTER TABLE 構文」を参照してください。 行ベースのレプリケーション MySQL Cluster で行ベースのレプリケーションを使用するときは、バイナリロギングを無効にすることができません。つまり、
NDB
ストレージエンジンはsql_log_bin
の値を無視します。(Bug #16680)