MySQL分区表无法创建不含分区键的唯一索引，因其全局唯一约束必须显式包含分区键列，否则报错ERROR 1503；根本原因是MySQL仅在单个分区内校验唯一性，不支持跨分区维护全局唯一。
为什么 MySQL 分区表上建不了不含分区键的唯一索引
因为 mysql 的分区机制要求所有全局唯一约束（包括 primary key 和 unique key）必须**显式包含分区键列**，否则直接报错：error 1503 (hy000): a primary key must include all columns in the table's partitioning function。这不是 bug，是设计限制——mysql 需要靠分区键快速定位数据，若唯一性检查跨分区，就无法保证高效和一致性。
常见错误现象：
- 执行
ALTER TABLE t ADD UNIQUE (email)报错，而email不在PARTITION BY RANGE (id)的分区键里 - 建表时写
PRIMARY KEY (id)但分区键是created_at，直接失败
根本原因：MySQL 不支持跨分区维护全局唯一性，它只在单个分区内部校验唯一索引。绕过方式不是“禁用检查”，而是重构约束逻辑。
如何让唯一性约束「覆盖分区键」但又不破坏业务语义
最常用做法是把分区键加进唯一索引，形成复合约束。比如按 created_at 分区，又要保证 order_no 全局唯一，就改用 UNIQUE KEY (order_no, created_at)。
但要注意两点：
- 业务上
order_no本身已全局唯一，加created_at只是满足语法，不会增强语义；反而可能因时间精度问题（如秒级分区 + 毫秒级写入）导致误判冲突 - 如果分区键是
YEAR(created_at)这类表达式，索引里也得用相同表达式，不能只写created_at，否则索引无效 - 查询时若只用
WHERE order_no = ?，该复合索引仍能走前导列，性能影响小；但若查WHERE created_at > ?再过滤order_no，效率会下降
示例：
CREATE TABLE orders ( id BIGINT, order_no VARCHAR(32), created_at DATETIME, PRIMARY KEY (id, created_at), UNIQUE KEY uk_order_no_time (order_no, created_at) ) PARTITION BY RANGE (YEAR(created_at)) (...);
用 LOCAL 唯一索引替代 GLOBAL 约束的适用场景与风险
MySQL 支持 LOCAL 索引（CREATE UNIQUE INDEX ... LOCAL），它在每个分区内独立维护唯一性，不要求包含分区键。但它只保证「单个分区内唯一」，不等于全局唯一。
适合场景：
- 数据天然隔离，比如按
tenant_id分区，且业务明确不同租户可重名（如tenant_id=1和tenant_id=2都能有user123） - 写入路径可控，应用层已做全局去重（比如通过分布式 ID 或 Redis 锁），数据库只做兜底
风险点：
- 无法防止跨分区重复插入，DB 层失去约束能力
-
SHOW CREATE TABLE中看不到LOCAL标记，容易误以为是全局约束 - 分区合并（
ALTER TABLE ... REORGANIZE PARTITION）时，LOCAL 索引需重建，期间可能短暂失效
真正绕不开？那考虑放弃分区表或换方案
如果业务强依赖「非分区键字段的全局唯一约束」，又不愿妥协语义或引入应用层复杂度，分区表本身就不是最优选。
可评估的替代路径：
- 用普通表 + 归档策略（如按月建表 + 视图 union），唯一索引照常建，运维成本换约束自由
- 迁移到支持全局索引的引擎，比如 TiDB（
ADD UNIQUE INDEX ... GLOBAL）或 PostgreSQL 分区 +EXCLUDE约束 - 保留分区表结构，但把唯一性检查下沉到应用层或前置服务（如用 Kafka + Flink 实时去重），数据库只存数据
别低估分区键耦合带来的长期维护成本——加个新唯一字段、改个分区策略、做数据迁移，都可能卡在这条规则上。越早确认是否真需要分区，越不容易在唯一性上反复打补丁。
