首页 > 数据库 > MySQL

MySQL 分区表怎么处理跨分区唯一键：分区列约束与建表取舍

来源：17golang原创

时间：2026-08-30 22:21:29 501浏览收藏

订单表准备按 tenant_id 做 HASH 分区时，最先撞上的往往不是分区数量，而是原来的唯一键。只要表上有唯一键，MySQL 就要求分区表达式里的列同时出现在每一个唯一键里；主键也算唯一键。于是 UNIQUE KEY (external_ref) 这种看似合理的写法，在按租户分区的表上会直接失去建表资格。

先列出所有主键和唯一键，再决定分区列。若分区表达式使用 tenant_id，就必须让 tenant_id 进入每一个唯一键，或者重新评估这张表是否真的适合分区。

要点速览

分区表达式中的每一列都必须出现在表的每一个唯一键中。
PRIMARY KEY 也属于唯一键，不能只修改普通 UNIQUE KEY。
业务唯一性若是“租户内唯一”，把 tenant_id 放进联合键通常更贴合语义。
若业务要求全局唯一，分区表本身未必是合适的存储边界，应先确认查询与约束模型。

为什么按 tenant_id 分区会牵动所有唯一键

MySQL 的分区表由分区表达式决定一行落在哪个分区，而唯一键需要在表的约束范围内判断重复。为了让这个判断不依赖跨分区扫描，MySQL 8.4 规定：分区表达式使用的每个列，都要出现在每一个唯一键中。规则看起来严格，却能提前暴露“分区边界”和“唯一性边界”互相矛盾的问题。

例如，订单表有 PRIMARY KEY (order_id)，还有 UNIQUE KEY uk_external_ref (external_ref)。如果再写 PARTITION BY HASH (tenant_id)，两个唯一键都缺少 tenant_id，建表设计就不成立。不是把分区数从 8 改成 16 就能解决。

orders 表中 tenant_id 分区表达式与主键和租户业务唯一键的静态约束关系 — 图1：查看 orders、tenant_id、PRIMARY KEY 和 UNIQUE KEY 的边界，理解分区列为何必须进入全部唯一键。

先把订单表的唯一性说清楚

改 DDL 以前，先问一句：external_ref 是全平台唯一，还是只要求同一个租户内不重复？这两个答案会导向完全不同的设计。

租户内唯一：联合键表达真实业务边界

如果外部订单号只在租户内部唯一，可以把约束写成 UNIQUE KEY uk_tenant_ref (tenant_id, external_ref)。主键也相应写成 PRIMARY KEY (tenant_id, order_id)，让两个唯一键都包含分区列：

CREATE TABLE orders (
  tenant_id BIGINT NOT NULL,
  order_id BIGINT NOT NULL,
  external_ref VARCHAR(64) NOT NULL,
  created_at DATETIME NOT NULL,
  PRIMARY KEY (tenant_id, order_id),
  UNIQUE KEY uk_tenant_ref (tenant_id, external_ref)
)
PARTITION BY HASH (tenant_id)
PARTITIONS 8;

这里的关键不是“联合键更长”，而是约束终于和业务含义一致：同一个 tenant_id 下不能有重复的 external_ref，不同租户可以各自使用相同的外部编号。

orders 表的 tenant_id、order_id、external_ref 与两个联合键的静态字段关系 — 图2：联合主键和租户业务唯一键共同覆盖 tenant_id，字段关系与 HASH 分区边界保持一致。

全局唯一：不要用租户内联合键冒充全局约束

如果业务明确要求所有租户的 external_ref 全局唯一，把它改成 (tenant_id, external_ref) 会改变语义：不同租户出现同一个外部编号时不再冲突。这个结果可能让建表成功，却让重复数据悄悄进入系统。

此时有三个方向可评估：保留非分区表承载这条全局约束；把全局编号放到单独的唯一性登记表；或者改变分区列，使它和真正需要的唯一边界一致。不要为了通过 DDL 校验，直接删掉唯一键。

改表前检查哪些约束和查询路径

真实迁移前，先用元数据确认现有索引，再对照业务 SQL。可以从 SHOW CREATE TABLE orders 开始，逐个记录主键和唯一键的列顺序。列是否出现在键中是一回事，键是否还能支撑常用查询是另一回事。

SHOW CREATE TABLE orders;

SELECT INDEX_NAME, NON_UNIQUE, SEQ_IN_INDEX, COLUMN_NAME
FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
ORDER BY INDEX_NAME, SEQ_IN_INDEX;

重点核对三类场景：按 tenant_id 查租户订单，按 tenant_id + external_ref 做幂等写入，以及只拿 order_id 查单。若主键从单列变成 (tenant_id, order_id)，只传 order_id 的查询就不能想当然地继续走同一条访问路径，应用层可能需要补租户条件或增加另一个索引。