Not all charsets and collations supported; see Section C.10.6, « MySQL Cluster-4.1.6, 10 octobre 2004 » for a list of those that are supported.

There are no prefix indexes; only entire fields can be indexed.

Text indexes are not supported.

Geometry datatypes (WKT and WKB) are not supported.

There is no partial rollback of transactions. A duplicate key or similar error will result in a rollback of the entire transaction.

A number of hard limits exist which are configurable, but available main memory in the cluster sets limits. See the complete list of configuration parameters in Section 16.4.4, « Fichier de configuration ». Most configuration parameters can be upgraded online. These hard limits include:

Database names, table names and attribute names cannot be as long in NDB tables as with other table handlers. Attibute names are truncated to 31 characters, and if not unique after truncation give rise to errors. Database names and table names can total maximum of 122 characters. (That is, the maximum length for an NDB Cluster table name is 122 characters less the number of characters in the name of the database of which that table is a part.)

In MySQL 4.1 and 5.0, all Cluster table rows are of fixed length. This means (for example) that if a table has one or more VARCHAR fields containing only relatively small values, more memory and disk space will be required when using the NDB storage engine than would be for the same table and data using the MyISAM engine. We are working to rectify this issue in MySQL 5.1.

The maximum number of metadata objects is limited to 1600, including database tables, system tables, indexes and BLOBs.

The maximum number of attributes per table is limited to 128.

The maximum permitted size of any one row is 8k, not including data stored in BLOB columns.

The maximum number of attributes per key is 32.

The foreign key construct is ignored, just as it is in MyISAM tables.

Savepoints and rollbacks to savepoints are ignored as in MyISAM.

The query cache is disabled, since it is not invalidated if an update occurs on a different MySQL server.

There are query performance issues due to sequential access to the NDB storage engine; it is also relatively more expensive to do many range scans than it is with either MyISAM or InnoDB.

The Records in range statistic is not supported, resulting in non-optimal query plans in some cases. Employ USE INDEX or FORCE INDEX as a workaround.

Unique hash indexes created with USING HASH cannot be used for accessing a table if NULL is given as part of the key.

The only supported isolation level is READ_COMMITTED. (InnoDB supports READ_COMMITTED, REPEATABLE_READ, and SERIALIZABLE.) See MySQL Cluster Backup Troubleshooting for informaiton on how this can effect backup/restore of Cluster databases.

No durable commits on disk. Commits are replicated, but there is no guarantee that logs are flushed to disk on commit.

ALTER TABLE is not fully locking when running multiple MySQL servers (no distributed table lock).

MySQL replication will not work correctly off if updates are done on multiple MySQL servers. However, if the database partitioning scheme done at the application level, and no transactions take place across these partitions, then replication can be made to work.

Autodiscovery of databases is not supported for multiple MySQL servers accessing the same MySQL Cluster. However, autodiscovery of tables is supported in such cases. What this means is that after a database named db_name is created or imported using one MySQL server, you should issue a CREATE DATABASE db_name; statement on each additional MySQL server that access the same MySQL Cluster. (As of MySQL 5.0.2 you may also use CREATE SCHEMA db_name;.) Once this has been done for a given MySQL server, that server should be able to detect the database tables without error.

All machines used in the cluster must have the same architecture; that is, all machines hosting nodes must be either big-endian or little-endian, and you cannot use a mixture of both. For example, you cannot have a management node running on a PPC which directs a storage node that is running on an x86 machine. This restriction does not apply to machines simply running mysql or other clients that may be accessing the cluster's SQL nodes.

It is not possible to make online schema changes such as those accomplished using ALTER TABLE or CREATE INDEX. (However, you can import or create a table that uses a different storage engine, then convert it to NDB using ALTER TABLE tbl_name ENGINE=NDBCLUSTER;.)

Online adding or dropping nodes is not possible (the cluster must be restarted in such cases).

When using multiple management servers one must give nodes explicit IDs in connectstrings since automatic allocation of node IDs does not work across multiple management servers.

When using multiple management servers one must take extreme care to have the same configurations for all management servers. No special checks for this are performed by the cluster.

The maximum number of storage nodes is 48.

The total maximum number of nodes in a MySQL Cluster is 63. This number includes all MySQL Servers (SQL nodes), storage nodes, and management servers.