mysql数据库自增id和uuid选择

自增ID的优缺点，不适合以自增ID主键作为主键的情况，UUID介绍说明，uuid是什么，uuid的组成，UUID作为主键优缺点，mysql8.0的uuid_to_bin()函数分析及实现，mysql有序UUID实战，自定义uuid，自增id主键与自定义主键的选择建议，JDBCUtilsByDruid工具类，mysql数据类型binary，mysql函数hex()，mysql函数unhex()，bin_to_binary(uuid(),true)详细说明与实战/示例演示，什么是uuid

当数据非常大的时候会进行分库分表， 此时自增的 id 会带来业务上的问题（不同的表会产生相同的 id 值） 因此可以考虑使用雪花 id，生成雪花 id 可以使用开源的工具类生成，（例如：hutool） 雪花 id 是一个长度 64 位的 long 类型的 id。如果是小项目可以考虑使用自增id，中大型以上的项目就可以使用 UUID 和 雪花ID。

在MySQL中设计表的时候，MySQL官方推荐不要使用uuid或者不连续不重复的雪花id(long型且唯一)，而是推荐连续自增的主键id，官方的推荐是auto_increment。那么为什么不使用雪花id或者uuid呢？让我们来探讨分析一下这个问题的原因。

自增iduuidUUID是UniversallyUniqueIdentifier的缩写，它是在一定的范围内（从特定的名字空间到全球）唯一的机器生成的标识符。通用唯一标识符的意思，可以以业务实际userid为主键比如QQ号手机号等雪花id相比UUID无序生成的id而言,雪花算法是有序的（有时间参数）,而且都是由数字组成。雪花id最大为64位,符合java中long的长度64位。适用于大规模分布式。.........

在数据库设计中，选择适当的主键类型对于数据的存储和查询效率至关重要。在MySQL中，有些开发者倾向于使用UUID（Universally Unique Identifier）或者雪花ID作为主键，以确保数据的唯一性。然而，这种做法并不总是推荐的，因为它们在性能、存储空间和索引效率等方面存在一些问题。本文将探讨在MySQL中不推荐使用UUID或者雪花ID作为主键的原因，并与其他主键类型进行差异化对比。

主键使用ID与UUID的区别详解

一、自增还是UUID？数据库主键的类型选择自增还是UUID？这个问题看似简单，但是能诱发很多思考，也涉及到了很多细节。先说下uuid和 auto_increment(数据库自增主键)的优缺点吧，因为是个人理解，如有错误恳请指出：1、自增主键自增ID是在设计表时将id字段的值设置为自增的形式，这样当插入一行数据时无需指定id会自动根据前一字段的ID值+1进行填充。在MySQL数据库中，可通过sql语...

MySQL 的自增 ID（Auto Increment ID）是数据库表中最常用的主键类型之一。然而，在一些特定的场景下，例如当表中的数据量非常大或者应用场景特殊时，自增 ID 可能会达到其最大值。默认情况下，MySQL 的自增 ID 是一个BIGINT类型，这种类型的最大值是2^63 - 1，即，远远超过实际应用中可能达到的数量级。但是，在一些情况下，例如使用了INT类型或是数据表长期运行且 ID 的使用不当时，可能会遇到 ID 用尽的问题。

最近有小伙伴问博主关于主键ID的选取问题（UUID与自增ID）。我简单的总结一下； 如果站在数据库层面上，就拿mysql举例吧。默认采用的Innodb索引。 1.字段长度方面对比 博主在上一篇中也讲到了索引选取时候应该选择短的字段作为索引来降低索引的大小，这样在一个磁盘分片中可以存储更多的索引量，同样的缓存大小，可以容纳更多的索引量，从而加载的速度就会加快。从这个角...

在设计数据库表时，选择合适的主键类型是一个重要的决策。MySQL中，主键的选择通常在自增ID和UUID之间进行权衡。本文将探讨这两种主键类型的优缺点，以及在不同场景下的适用性。

雪花算法生成的 id，包括 符号位（1位），时间戳( 41位) ，数据中心ID (5位)， 机器ID(5位)， 序列号(12位)。序列号 (12位) ：对于某个机器/进程， 每生成 一个ID，序列号就加1，这个数字每毫秒开始时都会被重置 为0。雪花id 的生成依赖于机器的时钟，如果时钟回拨或者时钟不同步，可能会导致生成的id不唯一。雪花id 占用的存储空间较大，通常为64位，如果作为主键，会占用更多的存储空间。雪花算法，可以生成唯一id，id 只包含数字， 长 64位。1.不适用于分布式系统。

自增还是UUID? 数据库主键的类型该如何选择?

也可以根据自己业务需求，自己定义主键。

最近在建表选择主键的时候有些纠结，我们经常使用的主键有两种UUID和自增ID，不知道选哪一种好。之前一直没有总结过这两种主键的区别，于是今天去总结了一下这两种主键的区别、优缺点，以便为我们以后主键选择提供一些参考。

特性UUID 主键自增主键唯一性全球唯一在单个数据库中唯一，需要额外处理分布式环境存储空间较大（16 字节）较小（通常为 4 字节或 8 字节）性能插入性能较低（由于随机生成导致索引分散）插入性能较高（顺序插入，索引性能较好）可读性较差（较长，难以记忆）较好（简单数字，易于理解）适用场景分布式系统、跨平台、跨数据库单机数据库、性能要求高的应用安全性难以推测数据插入顺序，较为安全可推测插入顺序，可能暴露业务信息。

全局唯一，绝对不会出现重复的ID，且ID整体趋势递增。高可用，服务完全基于分布式架构，即使MySQL宕机，也能容忍一段时间的数据库不可用。高并发低延时，在CentOS 4C8G的虚拟机上，远程调用QPS可达5W+，TP99在1ms内。接入简单，直接通过公司RPC服务或者HTTP调用即可接入。

又碰到一个小白问题。数据库id使用数字自动累加还是使用uuid好？这是要分情况的：1、先要弄清楚这两种id的区别。 数据库id用数字优点：有利于排序，而且肉眼看起来会比较舒服；自动累加，可以计算。缺点：有上限，一般用int型的话好比较好记，如果用long型的话记起来也会比较费劲。缺点里面要命的是他的上限问题。如果超过数据表的数据是无限的，那就不要用，否则将来会出麻烦。 数据库id用uuid优点：重复几率很小，几乎不可能，算出来的32位长度的uuid是根据时间和本机信息加密出来的，所以很难重复;

MySQL的自动增加字段和UUID都是生成唯一标识符的有效方法，但它们各有优缺点和适用场景。

UUID与自增ID的核心差异在于：自增ID（4-8字节）具有存储紧凑、插入高效、索引友好等优势，适合单体高吞吐应用；而UUID（16字节）具有全局唯一性，适合分布式系统和需要前端生成ID的场景。性能测试显示自增ID插入速度比UUID快2-3倍，因其避免了B+树页分裂。实际应用中，单体系统推荐自增ID，分布式系统推荐UUID，混合方案则可结合两者优势。有序UUID（如UUIDv7）能部分解决性能问题，是折中选择。