22.2.5 KEY Partitioning
Partitioning by key is similar to partitioning by hash, except that where hash partitioning employs a user-defined expression, the hashing function for key partitioning is supplied by the MySQL server. NDB Cluster uses
MD5() for this purpose; for tables using other storage engines, the server employs its own internal hashing function which is based on the same algorithm as
The syntax rules for
CREATE TABLE ... PARTITION BY KEY are similar to those for creating a table that is partitioned by hash. The major differences are listed here:
KEYis used rather than
KEYtakes only a list of zero or more column names. Any columns used as the partitioning key must comprise part or all of the table's primary key, if the table has one. Where no column name is specified as the partitioning key, the table's primary key is used, if there is one. For example, the following
CREATE TABLEstatement is valid in MySQL 5.7:
CREATE TABLE k1 ( id INT NOT NULL PRIMARY KEY, name VARCHAR(20) ) PARTITION BY KEY() PARTITIONS 2;
If there is no primary key but there is a unique key, then the unique key is used for the partitioning key:
CREATE TABLE k1 ( id INT NOT NULL, name VARCHAR(20), UNIQUE KEY (id) ) PARTITION BY KEY() PARTITIONS 2;
However, if the unique key column were not defined as
NOT NULL, then the previous statement would fail.
In both of these cases, the partitioning key is the
idcolumn, even though it is not shown in the output of
SHOW CREATE TABLEor in the
PARTITION_EXPRESSIONcolumn of the
Unlike the case with other partitioning types, columns used for partitioning by
KEYare not restricted to integer or
NULLvalues. For example, the following
CREATE TABLEstatement is valid:
CREATE TABLE tm1 ( s1 CHAR(32) PRIMARY KEY ) PARTITION BY KEY(s1) PARTITIONS 10;
The preceding statement would not be valid, were a different partitioning type to be specified. (In this case, simply using
PARTITION BY KEY()would also be valid and have the same effect as
PARTITION BY KEY(s1), since
s1is the table's primary key.)
For additional information about this issue, see Section 22.6, “Restrictions and Limitations on Partitioning”.
Columns with index prefixes are not supported in partitioning keys. This means that
VARBINARYcolumns can be used in a partitioning key, as long as they do not employ prefixes; because a prefix must be specified for
TEXTcolumns in index definitions, it is not possible to use columns of these two types in partitioning keys. In MySQL 5.7, columns using prefixes are permitted when creating, altering, or upgrading partitioned tables, even though they are not included in the table's partitioning key. This is a known issue in MySQL 5.7 which is addressed in MySQL 8.0, where this permissive behavior is deprecated, and the server displays appropriate warnings or errors when attempting to use such columns in these cases. See Column index prefixes not supported for key partitioning, for more information and examples.Note
Tables using the
NDBstorage engine are implicitly partitioned by
KEY, using the table's primary key as the partitioning key (as with other MySQL storage engines). In the event that the NDB Cluster table has no explicit primary key, the “hidden” primary key generated by the
NDBstorage engine for each NDB Cluster table is used as the partitioning key.
If you define an explicit partitioning scheme for an
NDBtable, the table must have an explicit primary key, and any columns used in the partitioning expression must be part of this key. However, if the table uses an “empty” partitioning expression—that is,
PARTITION BY KEY()with no column references—then no explicit primary key is required.
You can observe this partitioning using the ndb_desc utility (with the
For a key-partitioned table, you cannot execute an
ALTER TABLE DROP PRIMARY KEY, as doing so generates the error ERROR 1466 (HY000): Field in list of fields for partition function not found in table. This is not an issue for NDB Cluster tables which are partitioned by
KEY; in such cases, the table is reorganized using the “hidden” primary key as the table's new partitioning key. See Chapter 21, MySQL NDB Cluster 7.5 and NDB Cluster 7.6.
It is also possible to partition a table by linear key. Here is a simple example:
CREATE TABLE tk ( col1 INT NOT NULL, col2 CHAR(5), col3 DATE ) PARTITION BY LINEAR KEY (col1) PARTITIONS 3;
LINEAR has the same effect on
KEY partitioning as it does on
HASH partitioning, with the partition number being derived using a powers-of-two algorithm rather than modulo arithmetic. See Section 22.214.171.124, “LINEAR HASH Partitioning”, for a description of this algorithm and its implications.