使用雪花id或uuid作为Mysql主键，被老板怼了一顿！

使用雪花id或uuid作为Mysql主键，被老板怼了一顿！

推荐：一：mysql和程序实例

1.1：为解答此问题，我们构建了三张表：user_auto_key, user_uuid, user_random_key。每张表的主键采用不同的生成策略，其余字段保持一致，以控制变量法测试表的插入速度和查询效率。这里的随机key指的是使用雪花算法生成的、前后不连续、不重复、无规律的ID，长度为18位的long值。

1.2：理论阐述后，直接上程序实践。利用spring的jdbcTemplate实现增查测试，采用springboot+jdbcTemplate+junit+hutool框架。程序在相同环境下生成同等数量的数据，通过插入10w数据分析效率。所有数据通过随机生成，确保真实效果。程序已上传至gitee，详情可见文底。

1.3：程序写入结果展示

1.4：效率测试结果分析

在已有130w数据量时，测试插入10w数据，发现uuid插入效率垫底。随着数据量增加至100w左右，uuid效率下降明显。效率排名为：auto_key > random_key > uuid。为何出现这种现象？带着疑问，我们接下来探讨。

二：使用uuid和自增ID的索引结构对比

2.1：自增ID的内部结构：自增值顺序存储，提升页面填充率，减少页分裂和碎片生成。新插入的行总是紧挨着已有最大数据行，定位快，减少额外消耗。

2.2：uuid索引的内部结构：因无规律性，新行位置需动态分配，导致大量额外操作。数据分布不均，增加页分裂，页分裂导致数据移动，插入效率低。

2.3：自增ID的缺点：暴露业务增长信息、并发插入导致锁争用、自增锁机制性能损失。优化需要调整innodb_autoinc_lock_mode配置。

使用innodb时，应按照主键自增顺序插入，并尽可能使用单调递增的聚簇键值。

三：总结

本文从提出问题、建表至使用jdbcTemplate测试不同ID生成策略，深入分析ID机制在mysql索引结构中的表现及其优缺点。详细解释了uuid和随机不重复ID在数据插入中的性能损耗，强调在实际开发中，遵循mysql官方推荐使用自增ID。mysql内部优化点众多，值得深入学习。2024-11-03