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.
NDB storage engine
does not support
which are possible for
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 22.214.171.124, “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.
MySQL Cluster and geometry data types.
Geometry data types (
WKB) are supported in
NDB tables in MySQL 5.1
(including MySQL Cluster NDB 6.X and 7.X through 7.1).
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 NDB tables with user-defined partitioning.
Support for user-defined partitioning for MySQL Cluster is
restricted to [
KEY partitioning. Beginning with MySQL
5.1.12, using any other partitioning type with
ENGINE=NDBCLUSTER in a
CREATE TABLE statement
results in an error.
It is possible to override this restriction, but doing so is not supported for use in production settings. For details, see User-defined partitioning and the NDB storage engine (MySQL Cluster).
Default partitioning scheme.
As of MySQL 5.1.6, all MySQL Cluster tables are by default
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
NDBCLUSTER storage engine is
used instead. For additional discussion of these and
related issues, see Section 18.2.4, “KEY Partitioning”.
Beginning with MySQL Cluster NDB 6.2.18, MySQL Cluster NDB
6.3.25, and MySQL Cluster NDB 7.0.6,
CREATE TABLE and
ALTER TABLE statements that
would cause a user-partitioned
NDBCLUSTER table not to meet
either or both of the following two requirements are not
permitted, and fail with an error (Bug #40709):
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 17.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 18.3.1, “Management of RANGE and LIST Partitions” and
Section 13.1.7, “ALTER TABLE Syntax”.