MySQL 主键用自增 ID 还是 UUID？为什么会影响索引和写入性能？

知识点详解：一个主键，为什么会影响不止一棵树

主键决定聚簇索引怎样组织行

咱们假设订单表有主键，以及按用户查询的二级索引。InnoDB 的聚簇索引围绕主键组织数据，二级索引通过主键信息定位行。

MySQL 的 InnoDB 索引说明描述了这种结构。因此，主键较长时，不只是主键索引多占一点空间，二级索引也可能承受增加的键负担。

一张表有多个二级索引，差别可能被进一步放大。具体大小还受字段类型、页结构与压缩等条件影响，不能用固定倍数描述全部表。

插入顺序，影响写入落在什么位置

递增键通常让新记录集中到索引的一端。随机键则可能落在已有范围的不同位置，需要访问不同页，并可能产生页分裂。

这会影响缓存、写入局部性和空间利用，但不意味着“自增永远没有分裂”或“随机键每次都分裂”。真实结果取决于页状态、数据量和工作负载。

MySQL 自增处理说明还体现了生成与并发方面的配置。所以，自增也有自己的边界，包括跨数据库协调和编号暴露等需求，不能只看存储优势。

UUID 的版本与保存方式，要一起说明

UUIDv4 常见的随机特征，与 UUIDv7 的时间有序设计不同。RFC 9562定义了相关格式。

不过，v7 的有序特征不等于全局严格递增。时间精度、同一时间范围内的随机部分、生成器行为和时钟，都可能影响结果。

保存方式也有区别。二进制 16 字节和带连字符的 36 字符字符串，空间与比较方式不同。字符编码、排序规则和转换方式又可能影响索引行为。

不能为了缩短就随意截断 UUID，也不能使用不适合该版本的字节重排方案。生成格式、编码和数据库比较顺序必须一起验证。

业务 ID 和聚簇主键，可以分开

如果外部接口需要难以枚举、能够独立生成的标识，而内部数据库希望使用紧凑递增键，可以分别设置内部主键和外部唯一标识。

这会多一个索引，也增加字段和查询转换成本，所以不是默认最优解。但它说明两个需求不必被同一个字段强行承担。

安全上也要注意：UUID 不是访问权限。即使标识难以猜测，接口仍然必须检查用户是否有权访问订单。

用目标表结构比较，不做脱离场景的跑分

可以保持字段和二级索引一致，分别测试候选主键，观察索引大小、持续写入、范围查询和按二级索引查找的表现。

要记录数据量、并发、缓存状态和存储编码。只对空表插入几百行，通常不足以说明长期写入和索引维护成本。

最终选择还要满足生成位置、跨节点唯一、排序需要和迁移方式。一个存储更快的方案，如果不能满足 ID 生成约束，也不是完整答案。

面试官继续追问

UUIDv7 一定比自增 ID 快吗？

不能直接保证。它通常仍比紧凑整数长，有序程度和工作负载也不同。需要在同一表结构与条件下测量。

没有显式主键怎么办？

InnoDB 会按规则选择聚簇索引，必要时生成内部键。这不是省掉主键设计的理由，应用仍需要明确稳定的行标识。

自增 ID 能用于安全保护吗？

不能。是否容易枚举，与是否有权访问是两回事。授权必须独立设计。

面试速记卡

• 索引关系：聚簇索引按主键组织，二级索引也包含主键信息。
• 长度影响：主键变长可能放大多个索引成本。
• 顺序影响：集中追加与分散插入的访问模式不同。
• UUID 边界：版本、二进制编码和排序方式一起看。
• 选择依据：生成约束、表结构和实际工作负载。