推荐用自增整型作主键，因其契合InnoDB聚簇索引结构，写入高效、避免页分裂；主键不应带业务含义，以防变更引发双I/O及破坏顺序插入；无显式主键时InnoDB会隐式选择或生成ROWID，但不可控且有风险。
MySQL 主键设计是面试高频考点，核心围绕“为什么用自增主键”“主键能不能带业务含义”“没主键行不行”这几个关键点展开。回答时抓住存储结构（InnoDB 聚簇索引）和写入性能两个底层逻辑，就能立住观点。
为什么推荐用自增整型作主键
InnoDB 表数据直接存放在主键索引的叶子节点上，也就是“聚簇索引”。自增主键让新记录总追加在末尾，页满即开新页，写入高效、空间紧凑。反之，用身份证号、UUID 这类随机值作主键，新记录得插到中间位置，频繁触发页分裂、数据移动、磁盘读写，还会产生大量碎片。
实际影响包括：
- 插入性能明显下降，尤其高并发写入场景
- 表文件体积更大，备份恢复更慢
- 后续可能需要定期执行 OPTIMIZE TABLE 来重建表
主键为什么不能有业务含义
带业务含义的主键（比如订单号、手机号、邮箱）存在两个硬伤：
- 业务规则可能变更——一旦主键值要改，InnoDB 得先删原行再插新行，相当于两次I/O，还可能引发页分裂
- 天然不保证递增性——比如按时间生成的订单号若含日期段，跨天时就可能倒序，同样破坏B+树的顺序写入优势
主键的本质是“数据定位锚点”，不是业务标识。真正需要业务唯一性的字段，用唯一索引约束更合适。
没有显式主键会怎样
MySQL 不强制要求你定义主键，但 InnoDB 一定会自己找一个来当聚簇索引：
- 优先选第一个非空唯一索引
- 找不到就用内置的 6 字节 ROWID（隐式主键），它随插入顺序递增，但不可见、不可查、无法被外键引用
问题在于：ROWID 是内部机制，你无法控制；而且一旦表里加了唯一索引又删掉，聚簇索引可能悄悄切换，带来潜在风险。所以显式定义自增主键，是最稳妥、最透明的选择。
自增主键常见误区澄清
几个容易答错的点：
- 插入时指定 id 值，自增不会跳过：比如当前最大 id 是 5，你 insert into t values(10, ...)，下一条自增仍从 6 开始，不是 11
- id 不连续≠出错：事务回滚、批量插入失败、delete 后再 insert，都可能导致空缺，这是正常现象
- 自增不是绝对不能改：可通过 ALTER TABLE ... AUTO_INCREMENT = N 调整起点，但线上慎用，避免重复或冲突
