使用 KEY 而不是 HASH。KEY is used rather than HASH.

KEY 只接受零个或多个列名。任何用作分区键的列必须包含表的主键的全部或部分，如果表有主键的话。如果没有指定列名作为分区键，则使用表的主键（如果存在）。例如，以下 CREATE TABLE 语句在 MySQL 8.4 中是有效的：KEY takes 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 TABLE statement is valid in MySQL 8.4:

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;

但是，如果唯一键列未定义为 NOT NULL，则前述语句将会失败。However, if the unique key column were not defined as NOT NULL, then the previous statement would fail.

在这两种情况下，分区键都是id列，尽管它未在SHOW CREATE TABLE的输出中显示，也未在信息模式PARTITIONS表的PARTITION_EXPRESSION列中显示。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.

与其他分区类型不同，用于KEY分区的列不限制为整数或NULL值。例如，以下CREATE 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;

如果指定了不同的分区类型，上述语句将无效。（在这种情况下，简单地使用PARTITION BY KEY()也将有效，并且与PARTITION BY KEY(s1)具有相同的效果，因为s1是表的主键。）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.)

有关此问题的更多信息，请参见第 26.6 节，“分区的限制和限制”。For additional information about this issue, see Section 26.6, “Restrictions and Limitations on Partitioning”.

Columns with index prefixes are not supported in partitioning keys. This means that CHAR, VARCHAR, BINARY，以及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以及TEXT columns in index definitions, it is not possible to use columns of these two types in partitioning keys. In older versions of MySQL, 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.4, this is no longer allowed deprecated, and the server rejects any CREATE TABLE或者ALTER TABLE statement affecting a partitioned table in which one or more columns using prefixes occur with an error. See Column index prefixes not supported for key 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. In older versions of MySQL, 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.4, this is no longer allowed deprecated, and the server rejects any CREATE TABLE or ALTER TABLE statement affecting a partitioned table in which one or more columns using prefixes occur with an error. See Column index prefixes not supported for key partitioning.