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 = ?）大概率走全表扫描，不是加个索引就能解决的——得另建覆盖索引。
