MySQL主键选型：UUID字符串与自增Integer哪个更优？

一、性能维度对比 #

自增Integer主键优势 #

• 索引效率更高：MySQL主键默认采用B+树索引，自增Integer是连续数值，插入时会追加到索引树末尾，不会触发页分裂，磁盘IO开销小，索引结构始终紧凑。查询时B+树层级更少，缓存命中率更高，主键查询、关联查询速度明显更快。
• 数值比较更快：Integer是数值类型，数据库进行主键匹配、排序时的计算开销远低于字符串类型的UUID。

UUID主键的性能劣势 #

• 索引碎片化严重：UUID是随机字符串，插入时会随机写入索引树的不同位置，频繁触发页分裂，导致磁盘碎片增多，索引树松散，查询时需要遍历更多页，IO开销大。
• 存储空间更大：UUID字符串（如36c78530-7f1e-11ee-b962-0242ac120002）占用36字节，即使转成二进制存储也需16字节，远大于Integer的4字节。更大的主键会让索引占用更多内存和磁盘空间，进一步降低缓存效率。
• 字符串匹配开销高：字符串类型主键在等值查询、范围查询时，数据库需逐字符比较，比数值类型计算耗时更长。

二、其他维度差异 #

• 分布式场景适配：自增Integer在分库分表时易出现主键冲突，需依赖全局ID生成器（如雪花算法、数据库自增步长配置）保证唯一；UUID天然支持分布式环境，无需额外协调即可生成唯一ID，适合多节点独立写入场景。
• 数据安全性：自增主键的连续性让攻击者可通过遍历ID获取数据（比如猜/api/user/1后尝试/api/user/2），存在泄露风险；UUID的随机性能有效避免这类遍历攻击。
• 数据迁移与合并：多库合并时，自增主键大概率重复，需重新调整ID，操作成本高；UUID的全局唯一性让数据迁移、合并更顺畅，无需修改主键。

三、SQL数据库主键选型最佳实践 #

• 单库单表优先选自增数值类型：若无分布式需求，自增Integer/BIGINT是最优选择，兼顾性能、存储空间和维护成本。
• 分布式场景选有序全局ID替代UUID：若需分布式唯一ID，优先考虑雪花算法、美团Leaf这类生成有序数值ID的方案，既解决分布式唯一问题，又能保持自增主键的索引优势；若必须用UUID，建议存储为二进制格式（BINARY(16)）减少存储空间开销。
• 安全优先场景用UUID或加密ID：如果业务对数据防遍历有要求，选择UUID或者对自增ID进行加密处理（如哈希、加盐）后作为对外暴露的ID，内部仍用自增主键存储。
• 遵循主键核心原则：无论选择哪种类型，主键必须满足唯一、非空、不可变的要求，避免用业务字段（如手机号、邮箱）作为主键，防止业务变更导致主键失效。

内容的提问来源于stack exchange，提问作者Bojan Todorovic