content_image/870866.jpg content_image/870872.jpg
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 id  column, even though it is not shown in the output of SHOW CREATE TABLE  or in the PARTITION_EXPRESSION  column of the INFORMATION_SCHEMA.PARTITIONS  table. 

Unlike the case with other partitioning types, columns used for partitioning by KEY  are not restricted to integer or NULL  values. For example, the following CREATE TABLE  statement 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 s1  is the table’s primary key.) 

For additional information about this issue, see Section 24.6, “Restrictions and Limitations on Partitioning” . 

Columns with index prefixes are not supported in partitioning keys. This means that CHAR , VARCHAR , BINARY , and VARBINARY  columns can be used in a partitioning key, as long as they do not employ prefixes; because a prefix must be specified for BLOB  and TEXT  columns in index definitions, it is not possible to use columns of these two types in partitioning keys. Prior to MySQL 8.0.21, columns using prefixes were permitted when creating, altering, or upgrading a partitioned table, even though they were not included in the table’s partitioning key; in MySQL 8.0.21 and later, this permissive behavior is deprecated, and the server displays appropriate warnings or errors when one or more such columns are used. See Column index prefixes not supported for key partitioning, for more information and examples. 

<img src='content_image/870866.jpg'>

## Note 

Tables using the NDB  storage 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 NDB  storage engine for each NDB Cluster table is used as the partitioning key. 

If you define an explicit partitioning scheme for an NDB  table, 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. 

<img src='content_image/870872.jpg'>

You can observe this partitioning using the ndb_desc  utility (with the -p  option). 

## Important 

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 23, MySQL NDB Cluster 8.0 . 

