MySQL主键是唯一标识表中每行且非空的列或列组合，作为InnoDB聚簇索引键决定数据物理存储，支撑高效查询、外键关联与精准操作；推荐用BIGINT AUTO_INCREMENT代理主键，业务字段加UNIQUE约束。
MySQL中的主键是一列（或多个列的组合），它的值能唯一标识表中的每一行记录，且不允许为空（NOT NULL）和重复（UNIQUE）。它不只是一个约束，更是InnoDB存储引擎组织数据的核心依据。
主键的核心特性
主键不是普通索引，它自带三重硬性保障：
- 唯一性：同一张表中，任意两行的主键值不能相同；
- 非空性：主键字段不允许插入NULL值；
- 最小性：如果是复合主键，组成它的每个字段都应是必要且不可再少的——去掉任一列，就无法保证唯一标识整行。
主键在InnoDB中决定数据怎么存
InnoDB使用聚簇索引（Clustered Index）来组织表数据，而主键就是这个聚簇索引的键。这意味着：
- 表的实际数据行，就存放在主键索引的B+Tree叶子节点上；
- 如果没有显式定义主键，InnoDB会尝试找一个非空的唯一索引代替；找不到就自动生成6字节隐藏rowid；
- 按主键顺序插入数据时，写入效率最高，页分裂最少；乱序插入容易引发页分裂和空间浪费。
主键的实际作用与典型使用场景
主键的价值远超“标个号”，它直接支撑关键数据库能力：
- 高效查询：主键查询是最快路径，通常1–3次I/O即可定位数据行；
-
外键关联基础：订单表的
user_id作为外键，必须引用用户表的主键，才能保证关联有效性； -
避免误操作：没有主键时，
UPDATE或DELETE语句很难精准命中单行，易造成批量误改； -
逻辑设计锚点：用户表用
user_id BIGINT AUTO_INCREMENT，订单表用order_id CHAR(32)（如UUID），商品表用sku VARCHAR(20)——这些选择都围绕业务唯一性、稳定性与查询友好性展开。
选主键时要注意什么
不推荐直接用含业务含义的字段（比如身份证号、手机号、邮箱）当主键，原因包括：
- 可能变更（如用户换手机号），而主键一旦被外键引用，修改成本极高；
- 字符串主键比整型更占空间，会放大二级索引体积（因为二级索引叶子节点存的是主键值）；
- UUID虽然全局唯一，但无序插入导致聚簇索引频繁分裂，性能不如自增整型。
更稳妥的做法是：用BIGINT AUTO_INCREMENT做代理主键，同时对业务字段加UNIQUE约束保证语义唯一。
