primary key 可作用于单列或多个列组合,整张表仅能有一个主键;建表时直接定义联合主键最稳妥,需显式声明各列 not null,并用 primary key (col1, col2) 指定顺序,不可加单引号;alter table 补加前须确保无主键、所有列非空且唯一;联合主键不支持 auto_increment,外键及查询优化均需严格匹配列数与顺序。

PRIMARY KEY 必须作用于两个或以上列的组合,且整张表只能有一个主键(无论单列还是联合)。直接在 CREATE TABLE 语句中定义最稳妥,后期用 ALTER TABLE 补加容易踩坑。
建表时直接定义联合主键
这是最推荐、最不容易出错的方式。把所有参与联合主键的列都声明为 NOT NULL,然后在表定义末尾用 PRIMARY KEY (col1, col2) 指定组合。
-
NOT NULL必须显式写明——MySQL 不会自动给联合主键列加NOT NULL约束,漏写会导致建表失败或行为异常 - 列顺序影响索引结构和查询效率:比如
PRIMARY KEY (student_id, course_id)和(course_id, student_id)是两个不同的 B+ 树,前者支持WHERE student_id = ?,后者才支持WHERE course_id = ? - 不要对联合主键列加单引号:
PRIMARY KEY ('a', 'b')是错的,会报 “Unknown column 'a' in 'primary key'” —— 正确写法是PRIMARY KEY (a, b)
示例:
CREATE TABLE enrollment ( student_id INT NOT NULL, course_id INT NOT NULL, enrolled_at DATETIME, PRIMARY KEY (student_id, course_id) ) ENGINE=InnoDB;
已有表追加联合主键
用 ALTER TABLE 添加联合主键前,必须确保目标列已满足两个前提:全部 NOT NULL,且当前表没有主键(否则先 DROP PRIMARY KEY)。
- 如果原表已有主键,
ALTER TABLE t ADD PRIMARY KEY (a,b)会报错:Multiple primary key defined - 正确流程是:
ALTER TABLE t MODIFY a INT NOT NULL→ALTER TABLE t MODIFY b INT NOT NULL→ALTER TABLE t DROP PRIMARY KEY→ALTER TABLE t ADD PRIMARY KEY (a,b) - 注意:
DROP PRIMARY KEY不指定列名,MySQL 会删掉整个主键约束(不管单列还是联合)
联合主键和自增字段不能共存
AUTO_INCREMENT 只能属于主键中的**第一个列**,且该列必须是整型;一旦用了联合主键,就无法让其中任意一列自动递增(除非你把自增列单独设为主键,再用唯一索引+业务逻辑模拟“联合唯一”)。
- 下面语句会报错:
PRIMARY KEY (id, created_at), id INT AUTO_INCREMENT - 常见替代方案:保留一个单列
id BIGINT PRIMARY KEY AUTO_INCREMENT,再对业务上需要联合唯一的字段加UNIQUE (col1, col2) - 如果坚持用联合主键,插入时必须显式提供所有主键列的值,不能依赖自增
联合主键实际生效的关键点
联合主键真正起作用,靠的是底层唯一性约束 + 聚簇索引。但很多人忽略它对后续操作的影响:
- 外键引用必须完整匹配联合主键列数和顺序,比如引用
(a,b)的外键,必须也定义为(ref_a, ref_b),不能只引其中一个 -
INSERT IGNORE或ON DUPLICATE KEY UPDATE中的 “key” 指的就是这个联合主键,冲突判断基于全部列组合值 - 使用
DESCRIBE table_name查看时,Key列显示PRI的行不止一条——那是联合主键里每个列的标记,不代表多个主键
真正容易被忽略的是:联合主键一旦定义,就绑定了数据物理存储顺序(聚簇索引),后续按非前导列查询(如只有 WHERE course_id = ?)大概率走全表扫描,不是加个索引就能解决的——得另建覆盖索引。











