Some SQL statements relating to certain MySQL features produce
errors when used with
as described in the following list:
Temporary tables are not supported. Trying either to
create a temporary table that uses the
NDB storage engine or to
alter an existing temporary table to use
NDB fails with the error
Table storage engine 'ndbcluster' does not
support the create option 'TEMPORARY'.
Indexes and keys in NDB tables. Keys and indexes on MySQL Cluster tables are subject to the following limitations:
Attempting to create an index on an
NDB table column whose width is
greater than 3072 bytes succeeds, but only the first
3072 bytes are actually used for the index. In such
cases, a warning Specified key was too
long; max key length is 3072 bytes is
issued, and a
TABLE statement shows the length of the
index as 3072.
USING HASH keys and NULL.
Using nullable columns in unique keys and primary keys
means that queries using these columns are handled as
full table scans. To work around this issue, make the
NOT NULL, or re-create the
index without the
There are no prefix indexes; only entire columns can
be indexed. (The size of an
column index is always the same as the width of the
column in bytes, up to and including 3072 bytes, as
described earlier in this section. Also see
Section 188.8.131.52, “Unsupported or Missing Features in MySQL Cluster”,
for additional information.)
BIT column cannot be
a primary key, unique key, or index, nor can it be
part of a composite primary key, unique key, or index.
Like other MySQL storage engines, the
NDB storage engine can
handle a maximum of one
AUTO_INCREMENT column per table.
However, in the case of a Cluster table with no
explicit primary key, an
AUTO_INCREMENT column is
automatically defined and used as a
“hidden” primary key. For this reason,
you cannot define a table that has an explicit
AUTO_INCREMENT column unless that
column is also declared using the
KEY option. Attempting to create a table
AUTO_INCREMENT column that
is not the table's primary key, and using the
NDB storage engine, fails
with an error.
Restrictions on foreign keys.
Support for foreign key constraints in MySQL Cluster NDB
7.3 is comparable to that provided by
InnoDB, subject to the
Every column referenced as a foreign key requires an explicit unique key, if it is not the table's primary key.
ON UPDATE CASCADE is not supported
when the reference is to the parent table's primary
SET DEFAULT is not supported. (Also
not supported by
NO ACTION keywords are accepted
but treated as
RESCRICT. (Also the
same as with
Prior to MySQL Cluster NDB 7.3.5, when creating a table with foreign key referencing an index in another table, it sometimes appeared possible to create the foreign key even if the order of the columns in the indexes did not match, due to the fact that an appropriate error was not always returned internally. A partial fix for this issue in MySQL Cluster NDB 7.3.5 improves the error used internally to work in most cases; however, it is still possible for this situation to occur in the event that the parent index is a unique index. (Bug #18094360)
For more information, see Section 184.108.40.206, “Using FOREIGN KEY Constraints”, and Section 220.127.116.11, “FOREIGN KEY Constraints”.
MySQL Cluster and geometry data types.
Geometry data types (
WKB) are supported for
NDB tables. However, spatial
indexes are not supported.
Character sets and binary log files.
ndb_binlog_index tables are created
latin1 (ASCII) character set.
Because names of binary logs are recorded in this table,
binary log files named using non-Latin characters are not
referenced correctly in these tables. This is a known
issue, which we are working to fix. (Bug #50226)
Creating NDBCLUSTER tables with user-defined partitioning.
Support for user-defined partitioning in MySQL Cluster is
restricted to [
KEY partitioning. Using any other
partitioning type with
ENGINE=NDBCLUSTER in a
CREATE TABLE statement
results in an error.
Default partitioning scheme.
All MySQL Cluster tables are by default partitioned by
KEY using the table's primary key
as the partitioning key. If no primary key is explicitly
set for the table, the “hidden” primary key
automatically created by the
NDB storage engine is used
instead. For additional discussion of these and related
issues, see Section 19.2.5, “KEY Partitioning”.
The table must have an explicit primary key.
All columns listed in the table's partitioning expression must be part of the primary key.
If a user-partitioned
NDBCLUSTER table is created
using an empty column-list (that is, using
PARTITION BY [LINEAR] KEY()), then no
explicit primary key is required.
Maximum number of partitions for NDBCLUSTER tables.
The maximum number of partitions that can defined for a
NDBCLUSTER table when
employing user-defined partitioning is 8 per node group.
(See Section 18.1.2, “MySQL Cluster Nodes, Node Groups, Replicas, and Partitions”, for
more information about MySQL Cluster node groups.
DROP PARTITION not supported.
It is not possible to drop partitions from
NDB tables using
ALTER TABLE ... DROP PARTITION. The
other partitioning extensions to
REORGANIZE PARTITION, and
COALESCE PARTITION—are supported
for Cluster tables, but use copying and so are not
Section 19.3.1, “Management of RANGE and LIST Partitions” and
Section 13.1.7, “ALTER TABLE Syntax”.