怎么在MySQL中创建联合主键并理解对存储引擎底层的影响-mysql教程-PHP中文网

联合主键是单个覆盖多列的唯一聚簇索引，非多个主键；必须用PRIMARY KEY(a,b)单条声明，所有列自动NOT NULL，顺序影响B+树结构与查询性能。

怎么在mysql中创建联合主键并理解对存储引擎底层的影响

联合主键不是“多个主键”，而是单个索引覆盖多列

MySQL里不存在“多个主键”的概念。所谓联合主键，就是用 PRIMARY KEY(a, b) 语法把两个或更多字段一起声明为主键，InnoDB 会将它们组合成一个**唯一的、不可为空的聚簇索引**。这个索引就是整张表唯一的聚簇索引——它既是主键，也决定了数据的物理存储顺序。

常见错误是以为加了 PRIMARY KEY(a) 又加 PRIMARY KEY(b) 就能实现联合效果，这在语法上直接报错：ERROR 1068: Multiple primary key defined。必须写成一条声明。

联合主键中的所有列都自动 NOT NULL，无需额外声明
列顺序至关重要：PRIMARY KEY(user_id, order_time) 和 PRIMARY KEY(order_time, user_id) 是两棵完全不同的B+树，查询效率差异可能极大
如果已有单列主键（比如自增 id），就不能再定义联合主键；想用业务字段组合做主键，必须先删掉原主键

联合主键强制使用 InnoDB，且彻底改变数据物理布局

MyISAM 不支持联合主键的语义约束（它允许重复、允许NULL），所以当你执行 CREATE TABLE ... PRIMARY KEY(a,b) 时，MySQL 会静默强制使用 InnoDB 引擎，哪怕你显式写了 ENGINE=MyISAM —— 这条建表语句会失败或被忽略。

更关键的是：联合主键作为聚簇索引，会让整张表的数据按 (a,b) 的字典序物理排序存储。例如：

INSERT INTO t (user_id, order_time, amount) VALUES
(1001, '2026-10-10 10:00:00', 99),
(1001, '2026-10-10 10:05:00', 120),
(1002, '2026-10-10 09:30:00', 88);

这三行在磁盘上就严格按 (1001,'2026-10-10 10:00:00') → (1001,'2026-10-10 10:05:00') → (1002,'2026-10-10 09:30:00') 的顺序存放。这种布局对 WHERE user_id = ? AND order_time BETWEEN ? AND ? 这类查询极友好，但对仅查 order_time 的查询基本无效。

联合主键无法使用自增特性：AUTO_INCREMENT 只能作用于单列，且该列必须是联合主键的最左列（如 PRIMARY KEY(id, user_id) 中 id 可设自增，但 user_id 不行）
没有显式主键时，InnoDB 会生成隐藏 rowid；但一旦定义了联合主键，这个隐藏ID就彻底消失，所有二级索引的叶子节点都存的是你定义的那组联合值（如 (user_id, order_time)），而不是某个单独ID

联合主键 vs 普通联合索引：回表路径完全不同

这是最容易混淆的点。假设你有一张订单表，用 PRIMARY KEY(user_id, order_time)，再建一个普通联合索引 KEY idx_status_time (status, order_time)：

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

走主键查询（如 SELECT * FROM t WHERE user_id = 1001 AND order_time > '2026-10-01'）：B+树一路走到叶子节点，数据就在那儿，零回表
走普通联合索引（如 SELECT * FROM t WHERE status = 'paid' AND order_time > '2026-10-01'）：先在 idx_status_time 树里找到匹配的叶子节点，里面只存了 (status, order_time, user_id)（注意：最后这个是主键值！因为主键是联合的，所以这里存的是完整联合主键值），然后再拿着这组值回到聚簇索引里去查整行——这个“拿着 (user_id, order_time) 去聚簇索引里再查一遍”的过程，就是回表，而且比单列主键回表开销更大

也就是说，普通联合索引的叶子节点存的是「联合主键全值」，不是某个ID。如果你的联合主键很长（比如含 UUID 字段），那每个二级索引的体积和回表成本都会显著上升。