为什么 MySQL 表通常推荐使用自增主键？随机主键有什么问题？

简化版

MySQL InnoDB 表通常推荐使用自增主键，因为 InnoDB 是聚簇索引，数据按主键顺序存放。自增主键写入基本是顺序追加，页分裂少、索引紧凑、缓存友好。随机主键如 UUID 会插入到 B+Tree 随机位置，容易造成页分裂、页移动、索引膨胀和写入性能下降。业务上可以内部用自增或趋势递增 bigint，外部再用不可猜测的业务单号。

详细版

InnoDB 的主键索引叶子节点存放整行数据，二级索引叶子节点存放主键值。因此主键设计会影响整张表的存储和查询性能。

自增 bigint 主键有几个优势：长度短，二级索引占用小；趋势递增，写入集中在索引末尾；比较和关联效率高。随机 UUID 主键长度大，插入位置随机，会导致 B+Tree 页分裂和缓存命中下降，二级索引也会变大。

但自增主键也有问题：对外暴露会泄露业务量，分库分表全局唯一较难，极端写入可能有热点页竞争。因此常见做法是内部主键用自增或趋势递增 ID，对外使用订单号、UUID 或加密后的标识。

完整版教学

一、InnoDB 聚簇索引决定了主键很重要

InnoDB 表的数据不是随便堆在磁盘上，而是按照主键组织成 B+Tree。主键索引的叶子节点存储整行数据，这叫聚簇索引。因此主键不仅是一个逻辑标识，还决定了数据物理组织方式。

如果主键设计不好，影响的不只是按主键查询，还会影响写入、二级索引大小、缓存命中率和磁盘 IO。面试问自增主键，本质上是在考你是否理解 InnoDB 的存储结构。

二、自增主键为什么写入友好

自增主键是递增的，新记录通常插入到 B+Tree 最右侧叶子页，类似追加写。追加写的好处是页分裂少、局部性好、缓存命中率高。数据库可以更稳定地维护索引结构。

相比之下，随机主键的新值可能落在索引树任意位置。某个中间页已经满了，又要插入新记录，就需要页分裂，把数据拆到新页中。页分裂会带来额外 IO、内存页调整和索引碎片，高并发写入时性能波动明显。

三、主键长度影响二级索引

InnoDB 的二级索引叶子节点保存的是二级索引键加主键值。也就是说，主键越大，所有二级索引都会跟着变大。如果主键是 bigint，只需要 8 字节；如果主键是 char(36) UUID，二级索引会膨胀很多。

索引变大意味着同样内存能缓存的索引页更少，查询可能需要更多 IO。数据量小时不明显，数据量到千万、亿级后差异会非常明显。

四、随机 UUID 的典型问题

UUID 的问题不是唯一性，而是随机和长。随机导致写入分散，长导致存储和索引成本高。使用 UUID 字符串作为主键还会让比较成本变高，占用更多网络传输和日志空间。

如果业务必须使用 UUID，至少可以考虑 binary(16) 存储，或者使用有序 UUID、UUIDv7 这类时间有序方案。它们能改善一部分问题，但仍然比 bigint 更重。

五、自增主键的缺点

自增主键也不是完美的。第一，对外暴露连续 ID 会泄露业务量，也容易被枚举。第二，分库分表后，每个库自增会冲突，需要额外设计。第三，在极高并发下，递增写入集中在热点页，可能有一定竞争，不过通常比随机页分裂更可控。

因此主键设计要区分内部和外部。内部主键服务数据库性能；外部业务单号服务安全、展示和跨系统对接。不要把一个 ID 同时承担所有目标。

六、和分布式 ID 的关系

很多分布式 ID 方案都强调趋势递增，就是为了兼顾 InnoDB 写入友好。Snowflake 生成的 ID 高位是时间戳，整体大致递增；号段模式生成的 ID 也递增。这些方案比随机 UUID 更适合作为 MySQL 大表主键。

但如果业务使用分库分表，还要考虑路由键。主键是否包含分片信息、是否能按时间归档、是否便于全局查询，都需要结合分片策略设计。

七、落地建议

普通业务表优先使用 bigint 类型的自增或趋势递增主键。不要依赖主键连续，因为事务回滚、插入失败、数据库重启都可能造成空洞。对外展示使用单独的业务编号，必要时做随机化、加密或加前缀。

如果已经使用 UUID 主键并遇到性能问题，可以评估是否改为 binary 存储、有序 UUID，或新增 bigint 内部主键。但主键迁移成本很高，需要考虑外键、索引、应用代码和历史数据。

还有一个面试常问点：为什么不建议用业务字段做主键。业务字段可能变化，长度也可能较长，还可能涉及组合唯一约束。主键最好稳定、短小、无业务含义。业务唯一性可以通过唯一索引保证，比如订单号唯一、用户手机号唯一，但内部关联和聚簇索引仍然优先使用稳定的数字主键。

如果表未来可能分库分表，自增主键还要提前规划。单库自增 ID 迁移到多库后，全局唯一性、路由规则和历史数据合并都会变复杂。常见做法是新系统直接使用趋势递增的分布式 bigint ID，或者在分库前引入外部业务单号，避免所有外部系统都依赖数据库自增主键。这样后续迁移时，内部主键变化不会影响外部接口和用户查询。

八、常见误区与追问

这道题不能只背概念，要把「MySQL 自增主键」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	MySQL 自增主键作为 InnoDB 聚簇索引写入顺序友好，但在分布式场景会有单点和扩展问题	不要停在名词解释
流程机制	插入行时申请 auto_increment -> InnoDB 按主键顺序写聚簇索引 -> 二级索引引用主键 -> 单库内保证递增 -> 跨库需要额外策略	说明触发方、存储方、确认点和兜底
工程取舍	BIGINT 自增主键顺序插入可减少页分裂，比随机 UUID 更适合高频写表	ID 方案没有全能答案，要在唯一性、性能、可读性、索引友好和运维复杂度之间取舍

MySQL 自增主键 面试拆解：
1. 插入行时申请 auto_increment
2. InnoDB 按主键顺序写聚簇索引
3. 二级索引引用主键
4. 单库内保证递增
5. 跨库需要额外策略

记忆钩子：先说明唯一性、趋势递增、吞吐、可用性和时钟依赖，再按方案取舍；回答时要紧扣「MySQL 自增主键」这道题，不要把相邻概念混成一段泛泛的分布式套话。

误区：MySQL 自增主键适合跨库全局 ID。 它只保证本实例表内递增，跨库要配置步长或使用外部生成器。
误区：自增主键一定连续。 事务回滚、批量插入和崩溃恢复都可能造成空洞。
误区：随机主键和自增主键插入性能一样。 随机主键更容易造成页分裂和缓存命中下降。
追问：为什么推荐 BIGINT？ 容量大，适合长期增长，避免 INT 溢出。
追问：自增锁会不会成为瓶颈？ 高并发和不同 innodb_autoinc_lock_mode 下表现不同，要压测。
追问：分库分表怎么做？ 不直接依赖各库自增，使用雪花、号段或设置不同步长。

九、加强记忆

InnoDB 数据按主键组织，自增主键短、递增、写入友好、二级索引小；随机 UUID 长、随机、容易页分裂和索引膨胀。内部主键优先考虑 bigint 趋势递增，对外 ID 可以另行设计，避免暴露业务量和被枚举。

简化版

详细版