The following limitations apply to the use of storage engines with user-defined partitioning of tables.
MERGE storage engine.
User-defined partitioning and the
storage engine are not compatible. Tables using the
MERGE storage engine cannot be partitioned.
Partitioned tables cannot be merged.
FEDERATED storage engine.
FEDERATED tables is not
supported. Beginning with MySQL 5.1.15, it is not possible to
FEDERATED tables at all.
CSV storage engine.
Partitioned tables using the
engine are not supported. Starting with MySQL 5.1.12, it is
not possible to create partitioned
tables at all.
BLACKHOLE storage engine.
Prior to MySQL 5.1.6, tables using the
BLACKHOLE storage engine also could not be
InnoDB storage engine.
InnoDB foreign keys and MySQL
partitioning are not compatible. Partitioned
InnoDB tables cannot have foreign key
references, nor can they have columns referenced by foreign
InnoDB tables which have or which are
referenced by foreign keys cannot be partitioned.
TABLE ... OPTIMIZE PARTITION does not work correctly
with partitioned tables that use the
storage engine. Use
ALTER TABLE ... REBUILD
ALTER TABLE ... ANALYZE
PARTITION, instead, for such tables. For more
Section 22.214.171.124, “ALTER TABLE Partition Operations”.
User-defined partitioning and the NDB storage engine (MySQL Cluster).
LINEAR KEY) is the only type of
partitioning supported for the
NDBCLUSTER storage engine.
Beginning with MySQL 5.1.12, it is not possible under normal
circumstances to create a MySQL Cluster table using any
partitioning type other than [
KEY, and attempting to do so fails with an
Exception (not for production): It is
possible to override this restriction by setting the
new system variable on MySQL
Cluster SQL nodes to
ON. If you choose to do
this, you should be aware that tables using partitioning types
[LINEAR] KEY are not supported in
production. In such cases, you can create and use
tables with partitioning types other than
LINEAR KEY, but you do this entirely at
your own risk.
The maximum number of partitions that can be defined for an
NDBCLUSTER table depends on the
number of data nodes and node groups in the cluster, the version
of the MySQL Cluster software in use, and other factors. See
NDB and user-defined partitioning,
for more information.
Beginning with MySQL Cluster NDB 6.2.18, MySQL Cluster NDB
6.3.25, and MySQL Cluster NDB 7.0.6,
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
table is created using an empty column-list (that is, using
PARTITION BY KEY() or
LINEAR KEY()), then no explicit primary key is
Upgrading partitioned tables.
When performing an upgrade, tables which are partitioned by
KEY and which use any storage engine other
NDBCLUSTER must be dumped
Same storage engine for all partitions. All partitions of a partitioned table must use the same storage engine and it must be the same storage engine used by the table as a whole. In addition, if one does not specify an engine on the table level, then one must do either of the following when creating or altering a partitioned table:
Do not specify any engine for any partition or subpartition
Specify the engine for all partitions or subpartitions