Rechercher dans le manuel MySQL
23.6.2 Partitioning Limitations Relating to Storage Engines
In MySQL 8.0, partitioning support is not actually
provided by the MySQL Server, but rather by a table storage
engine's own or native partitioning handler. In MySQL
8.0, only the InnoDB
storage engine provides a native partitioning handler. This
means that partitioned tables cannot be created using any other
storage engine.
MySQL Cluster's NDB storage engine
also provides native partitioning support, but is not
currently supported in MySQL 8.0.
ALTER
TABLE ... OPTIMIZE PARTITION does not work correctly
with partitioned tables that use InnoDB. Use
ALTER TABLE ... REBUILD PARTITION and
ALTER TABLE ... ANALYZE PARTITION, instead,
for such tables. For more information, see
Section 13.1.9.1, “ALTER TABLE Partition Operations”.
User-defined partitioning and the NDB storage engine (NDB Cluster).
Partitioning by KEY (including
LINEAR KEY) is the only type of
partitioning supported for the
NDB storage engine. It is not
possible under normal circumstances in NDB Cluster to create
an NDB Cluster table using any partitioning type other than
[LINEAR] KEY, and
attempting to do so fails with an error.
Exception (not for production): It is
possible to override this restriction by setting the
new system variable on NDB
Cluster SQL nodes to ON. If you choose to do
this, you should be aware that tables using partitioning types
other than [LINEAR] KEY are not supported in
production. In such cases, you can create and use
tables with partitioning types other than KEY
or LINEAR KEY, but you do this entirely at
your own risk.
The maximum number of partitions that can be defined for an
NDB table depends on the number of
data nodes and node groups in the cluster, the version of the
NDB Cluster software in use, and other factors. See
NDB and user-defined partitioning,
for more information.
The maximum amount of fixed-size data that can be stored per
partition in an NDB table is 128 TB.
Previously, this was 16 GB.
CREATE TABLE and
ALTER
TABLE statements that would cause a user-partitioned
NDB table not to meet either or
both of the following two requirements are not permitted, and
fail with an error:
The table must have an explicit primary key.
All columns listed in the table's partitioning expression must be part of the primary key.
Exception.
If a user-partitioned NDB table
is created using an empty column-list (that is, using
PARTITION BY KEY() or PARTITION BY
LINEAR KEY()), then no explicit primary key is
required.
Upgrading partitioned tables.
When performing an upgrade, tables which are partitioned by
KEY must be dumped and reloaded.
Partitioned tables using storage engines other than
InnoDB cannot be upgraded from MySQL 5.7 or
earlier to MySQL 8.0 or later; you must either drop the
partitioning from such tables with ALTER TABLE ...
REMOVE PARTITIONING or convert them to
InnoDB using ALTER TABLE ...
ENGINE=INNODB prior to the upgrade.
For information about converting MyISAM
tables to InnoDB, see
Section 15.6.1.3, “Converting Tables from MyISAM to InnoDB”.
Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-partitioning-limitations-storage-engines.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.
