联合主键是单个主键约束，由多列共同构成，创建唯一的聚簇索引（叶子存整行），强制各列非NULL且组合唯一；它不允许多个主键共存，支持最左前缀查询（如WHERE a=?），但不支持跳过首列的WHERE b=?，且修改成本高、字段总长宜≤1000字节。
联合主键是约束，不是“多个主键”的组合
联合主键（如 PRIMARY KEY (a, b)）本质是一个**单个主键约束**，只是它由多列共同构成。MySQL 不会为它额外建一个“主键索引+唯一索引”的组合，而是直接用这个多列组合构建**唯一的聚簇索引**——叶子节点存整行数据，且强制 a 和 b 都非 NULL、整体唯一。
常见错误现象：有人以为“加了联合主键，还能再给 a 单独建个索引”，其实没必要——(a, b) 这个联合主键本身已天然支持 WHERE a = ? 查询（最左前缀生效），但不支持 WHERE b = ? 独立查询。
- 联合主键不可部分为空：
a和b都必须有值，不允许任一列为NULL - 一张表仍只能有一个主键（哪怕它是联合的），不能同时存在
PRIMARY KEY (a, b)和PRIMARY KEY (c) - 它能被其他表用作外键引用，例如
FOREIGN KEY (ref_a, ref_b) REFERENCES t1(a, b)
复合唯一索引是二级索引，允许 NULL 且不参与物理组织
复合唯一索引（如 UNIQUE INDEX idx_ab (a, b)）是典型的**二级索引（非聚簇）**，它的 B+ 树叶子节点只存 (a, b) 值 + 主键值，查完还得回表取整行（除非覆盖查询）。它不改变表的数据物理顺序，也不承担标识整行的责任。
使用场景：比如用户表要求 (email, tenant_id) 组合唯一，但允许某条记录 email 为空（业务上表示“未绑定邮箱”），这时就不能用联合主键，而必须用复合唯一索引——因为 MySQL InnoDB 允许该索引中某列是 NULL，只要组合值不重复即可（注意：NULL 不参与唯一性比较，所以 (NULL, 1) 和 (NULL, 1) 是允许的）。
- 可以和主键共存，一张表能有多个复合唯一索引
-
UNIQUE约束只保证非 NULL 值的组合唯一，NULL被视为“未知”，不触发冲突 - 无法被用作外键的被引用目标（语法上不报错，但语义上不推荐，多数 ORM 和规范会拒绝）
为什么 WHERE b = ? 在联合主键上走不了索引
不是 MySQL 故意卡你，是 B+ 树结构决定的：联合主键 (a, b) 的索引项按字典序排序，先比 a，再比 b。当查询条件缺失最左列 a，就等于在电话簿里跳过“姓氏”直接找“名字”，数据库没法从根节点开始高效导航。
性能影响明显：这种查询大概率触发全表扫描，尤其当表大、b 区分度高时，优化器也不会“聪明地倒排”。
- 想支持
WHERE b = ?，得单独建INDEX (b)或把顺序改成(b, a)（但要重估主键语义是否合理） - 如果业务同时高频查
a、b、(a,b)，又需要b独立过滤，联合主键不是最优选——该用普通索引+复合唯一索引拆分职责 - 联合主键的列顺序一旦定下，修改成本高（需重建表），远高于增删二级索引
容易被忽略的底层代价：隐式主键与聚簇分裂
如果你没定义主键，InnoDB 会悄悄生成一个隐藏的 rowid 作为聚簇索引。此时即使你后来加了联合主键，也会触发一次全表重建——所有数据按新主键顺序重排，IO 和锁开销极大。这不是“加个约束”那么简单。
更隐蔽的问题是：联合主键值过大（比如用两个 VARCHAR(255)），会导致聚簇索引节点变宽，B+ 树层级加深，每次点查或多层范围扫描的磁盘 IO 次数上升。而复合唯一索引只存索引列+主键，影响范围小得多。
- 联合主键字段总长度建议控制在 1000 字节内（InnoDB 页大小限制）
- 避免用长文本、JSON 字段参与联合主键；复合唯一索引倒是可以配合前缀索引缓解
- 线上表加联合主键 = DDL 锁表操作，务必评估窗口期
