主键生成策略优劣比较以及应用

最新推荐文章于 2025-09-29 09:11:33 发布
原创 最新推荐文章于 2025-09-29 09:11:33 发布 · 2.3k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql

本文探讨了六种常见的主键生成策略，包括mysql自增长、时间戳+随机数、取最大值+1、单独建表、UUID及hilo算法等，并分析了各自的优缺点。

1、采用mysql自增长主键策略
：简单，不需要程序特别处理
：这种方法对以后如果项目移植到其它数据库上改动会比较大，oracle、 db2采用Sequence，mysql、sqlServer又采用自增长，通用性不好
2、使用时间戳+随机数
：实现简单，与数据库无关，移植性较好
：长度太长，最少也得20位，不仅占空间并且建索引的话性能会比较差点吧
3、每次取主键最大值+1做为新的主键
：主键长度可控，移植性较好
：并发写可能会造成主键冲突，对并发也不太好控制
4、单独建一个存放主键的表
：实现简单，移植性较好
：需要考虑并发问题，整个系统主键生成都依赖该表，性能影响可能较大
5、uuid生成策略
：不用访问数据库就能生成主键值，效率高，不用访问数据库就能生成，保证唯一性，移植方便
：长度长，占用空间大，无序，无意义，占用32位的字符长度
6.hilo高低位算法
通常订单编号、产品编号、物流编号、工人编号、批次编号等等各种各样的编号，都是由数字构成，有得会加一些前缀后缀，例如淘宝订单号。这种编号比较符合我们的理解和写记习惯

                                持续更新···
Java探索之Hibernate主键生成策略详细介绍
08-29
主要介绍了Java探索之Hibernate主键生成策略详细介绍，具有一定参考价值，需要的朋友可以了解下。
ID生成策略
07-12
`Identity`是一种常见的自增主键生成策略，在MySQL、DB2以及MS SQL Server等数据库系统中均有支持。它能够为每一行记录生成一个唯一的ID值。例如，在MySQL中创建一个表时可以这样定义： ```sql CREATE TABLE t_user...
主键生成策略
勃起吧，少年
04-03 201
  Assigned：主键由外部程序生成，无需Hibernate干预。 identity：采用数据库提供的主键生成机制，如MySql、DB2、SqlServer的自增主键。 sequence：使用数据库的sequence机制。 hilo：通过hi/lo 算法实现的主键生成机制，需要额外的数据库表保存主键生成历史状态。 seqhilo：与hilo 类似，通过hi/lo 算法实现的主键生成机制，只是...
Java-111 深入浅出 MySQL 分布式主键策略：UUID、SnowFlake、COMB、Redis、数据库ID表优劣全对比
永远好奇 无限进步
08-29 1221
在分布式系统中，主键策略决定了系统的扩展性和稳定性。传统自增ID虽简单，但在分库分表环境下易引发冲突。UUID具备全局唯一性与离线生成能力，适用于多系统合并与隐藏数据规模等场景，但无序性对数据库性能影响较大。COMB作为UUID的改进型，将时间戳嵌入UUID中，提升了插入效率和索引性能。SnowFlake以时间戳+机器ID+序列号组合生成64位整数ID，兼顾唯一性与有序性，适合高并发系统。数据库ID表通过独立表自增生成ID，虽简单直观，但存在性能瓶颈和单点风险。
主键策略,数据库id值生成方式及其优缺点
qq_42400763的博客
07-23 1029
主键策略 一:自动增长(AUTO INCREMENT) 可以在定义数据库时添加这一字段.实现id值的自动增长 例子:假设有三张表主键分别为 不足之处:当我们操作第二张表的时候需要根据上一张表的最后那个数据的id值来进行划分 二:UUID 每次生成一个随机唯一的值 缺点:排序不方便 三:redis实现 优点: 1.不依赖于数据库,灵活方便,且性能优于数据库 2.数据ID天然排序,对分页或者需要排序的结果很有帮助 缺点: 1.如果系统中没有Redis,还需要引入新的组件,增加系统的复杂度 2.需要编码和配置的工
【数据迁移的高效工具】：比较Excel与Oracle建表语句生成器的优劣
本文全面概述了数据迁移过程中的关键环节和工具应用，重点分析了Excel数据管理、Oracle数据库建表语句生成器的实际应用，并对两者的功能、性能和用户体验进行了比较评估。文章还探讨了数据清洗、预处理及迁移实施...
数据库主键的设计和思考
12-14
综上所述，自增主键和GUID主键各有优劣。自增主键适合简单场景，而GUID主键在复杂环境和系统集成中有更强的适应性。在实际应用中，应根据具体需求权衡选择。如果需要高度的唯一性和系统集成的灵活性，GUID主键可能是...
NoSQL与MySQL数据库对决：优劣对比与应用场景分析
[数据库 比较json](https://forum.dronebotworkshop.com/wp-content/uploads/wpforo/attachments/217/166-Control-Theory-Slides-006.jpeg) # 1. NoSQL与MySQL数据库概述** NoSQL和MySQL是两种截然不同的数据库类型...
43、单体应用向微服务架构重构的策略
melon的博客
09-29 23
本文详细探讨了将单体应用逐步重构为微服务架构的多种策略，包括以服务形式实现新功能、分离表示层与后端、提取业务能力为服务等方法。重点分析了提取服务过程中面临的领域模型拆分与数据库重构挑战，并提出了应对方案。同时对比了按需提取与有计划提取服务两种策略的优劣，最后给出了重构过程中的实践建议，帮助团队实现从单体到微服务的平稳过渡。
主键的生成策略
12-21 2758
主键的生成策略 的取值可以为： 1、  increment:用于long,short或者int类型生成的唯一标识。只有在没有其他进程往同一张表中插入数据时才能使用，在集群下不要使用 2、  identity:返回的标识符是long,short或者int类型。对DB2，MS SQL Service,Sybase和HypersonicSQL的内置标识符字段提供支持 3、  sequence：在
常见的主键生成策略
jzl_11的博客
03-20 411
后端常见的主键生成策略 1.数据库默认的主键自增长 auto_increment 优点：id连续，容易进行排序 缺点：分库分表时比较复杂，需要获取上一张表的末尾id 2.uuid 每次生成随机唯一的值 优点：id值全球唯一 缺点：没办法根据id进行排序 3.redis 假设有5台redis，初始值设置为1，2，3，4，5，每次获取新值都是在原有数据上增加5个步长。 A 1 6 11 B 2 7 12 C 3 8 13 D 4 9 14 E 5 10 15 4.MP自带生成策略 雪花算法 ...
四种主键选取策略的优缺点及相应的代码示例
langhua553的专栏
12-11 1950
我们在建立数据库的时候，需要为每张表指定一个主键，所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。 因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。当然，其它字段可以辅助我们在执行这些操作时消除共享冲 突，不过就不在这里讨论了。主键除了上述作用外，常常与外键构成参照完整性约束，防止出现数据不一致。所以数据库在
mysql主键生成策略_数据库主键生成策略
weixin_39983993的博客
01-20 895
在建立数据库的时候，需要为每张表指定一个主键，所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。数据库的主键生成有多种方式，每种方式都有其优点和缺点，应该根据不同的需求在主键的时间和空间效率上做平衡折中，从而选择不同的主键生成策略。归纳起来，对主键的选择主要有以下...
mysql主键生成策略 uuid_主键生成策略
weixin_32541333的博客
02-08 1127
网上搜集下来的1、assigned主键由外部程序负责生成，在 save() 之前必须指定一个。Hibernate不负责维护主键生成。与Hibernate和底层数据库都无关，可以跨数据库。在存储对象前，必须要使用主键的setter方法给主键赋值，至于这个值怎么生成，完全由自己决定，这种方法应该尽量避免。特点：可以跨数据库，人为控制主键生成，应尽量避免。2、increment由Hibernate从数据...
MySQL之主键ID生成策略
RedStone618的博客
12-17 7950
全局唯一id特点: 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求； 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能； 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求； 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所
对比一下不同的类似 uuid 这种生成的区别和优劣，全方面比对
最新发布
11-04
<think>我们被要求全面对比不同的类似UUID生成方式的区别和优劣。根据引用[1]和[4]，常见的分布式ID生成方案包括：自增ID、UUID、雪花算法（Snowflake）、美团Leaf（号段模式）等。此外，引用[3]还提到了一种多序列号生成器（基于雪花算法的变种）。我们将从多个维度进行对比。 对比维度： 1. 唯一性：是否全局唯一。 2. 有序性：生成的ID是否有序（对数据库索引性能很重要）。 3. 生成效率：生成速度如何。 4. 存储空间：ID占用的存储空间。 5. 适用场景：适合单机还是分布式，以及具体业务场景。 6. 缺点：各方案的不足之处。 1. 自增ID（Auto Increment） - 唯一性：在单库单表内唯一，但在分布式系统中可能重复（除非使用全局唯一自增ID）。 - 有序性：严格递增。 - 生成效率：高，数据库自动生成。 - 存储空间：通常为64位整数（8字节），空间占用小。 - 适用场景：单机应用，或者分库分表但通过设置不同起始值和步长来避免冲突（管理复杂）。 - 缺点：分布式环境下难以保证全局唯一；扩展性差（分库分表时需额外处理）；容易暴露业务数据量（如通过ID推断订单数量）。 2. UUID（Universally Unique Identifier） - 唯一性：理论上全球唯一（重复概率极低）。 - 有序性：无序（标准UUID版本1基于时间戳，但通常使用版本4随机生成）。 - 生成效率：高，本地生成，无需网络请求。 - 存储空间：通常为128位（16字节），占用空间较大。 - 适用场景：分布式系统中的唯一标识，对有序性要求不高的场景。 - 缺点：无序性导致数据库索引效率低（插入时可能引起B+树频繁分裂）；占用空间大；可读性差。 3. 雪花算法（Snowflake） - 唯一性：分布式系统内全局唯一（依赖机器ID的分配）。 - 有序性：整体趋势递增（时间戳在高位）。 - 生成效率：高，本地生成，性能好。 - 存储空间：64位整数（8字节），空间占用较小。 - 适用场景：分布式系统，需要有序ID且对性能要求高的场景（如高并发订单系统）。 - 缺点：依赖机器时钟，时钟回拨可能导致ID重复；需要管理机器ID（防止重复）。 4. 美团Leaf（号段模式） - 唯一性：全局唯一（由中央服务统一分发号段）。 - 有序性：趋势递增（号段内连续）。 - 生成效率：高，本地缓存号段，减少网络交互（批量获取）。 - 存储空间：64位整数（8字节）。 - 适用场景：分布式系统，尤其适合高并发且对性能敏感的场景。 - 缺点：需要依赖中央服务（可用性需保障）；号段用尽需重新获取（可能造成短暂阻塞）。 5. 多序列号生成器（Multi-Sequence Snowflake，引用[3]） - 这是雪花算法的变种，通过多个Snowflake生成器轮询使用，避免单个生成器成为瓶颈。 - 唯一性：全局唯一（每个生成器有独立的workerId）。 - 有序性：整体趋势递增，但同一时刻不同生成器生成的ID可能交错。 - 生成效率：更高，利用多核并行生成。 - 存储空间：64位整数（8字节）。 - 适用场景：超高并发场景，需要进一步提升生成速度。 - 缺点：时钟回拨问题依然存在；需要确保workerId分配不重复。 6. 业务字段组合 - 唯一性：由业务字段保证（如订单ID=商户ID+日期+序列号），需确保组合后唯一。 - 有序性：取决于业务字段（如日期有序）。 - 生成效率：中等，需要业务拼接。 - 存储空间：不定，可能较长（如字符串）。 - 适用场景：特定业务场景，需要业务含义嵌入ID。 - 缺点：灵活性低；扩展性差（业务变更可能影响ID结构）；较长字段占用存储空间大。 对比总结： | 特性 | 自增ID | UUID | 雪花算法 | 美团Leaf（号段） | 多序列Snowflake | 业务字段组合 | |--------------|-------------|---------------|------------------|------------------|------------------|--------------| | 唯一性 | 单机唯一 | 全局唯一 | 全局唯一 | 全局唯一 | 全局唯一 | 业务保证 | | 有序性 | 严格递增 | 无序 | 时间戳趋势递增 | 趋势递增 | 趋势递增（可能交错）| 可能有序 | | 生成效率 | 高（依赖DB）| 高（本地） | 高（本地） | 高（号段缓存） | 极高（多核并行） | 中 | | 存储空间 | 小（8字节） | 大（16字节） | 小（8字节） | 小（8字节） | 小（8字节） | 不定 | | 分布式适应性 | 弱 | 强 | 强 | 强 | 强 | 弱 | | 主要缺点 | 分布式难扩展| 无序、占用空间大| 时钟回拨 | 依赖中央服务 | 时钟回拨、workerId管理| 灵活性低 | 根据引用[4]，在金融系统中，分布式ID需要绝对唯一、生成快速、可追溯、高可用。雪花算法和美团Leaf是更常用的选择，但需要注意解决各自的缺点（如时钟回拨问题、中心化服务的高可用）。 引用[1]也指出：选择主键生成方式时，需综合考虑系统规模、扩展性、性能和业务需求。 参考文献： [^1]: 选择主键生成方式时，需综合考虑系统规模、扩展性、性能和业务需求。 [^3]: 多序列号生成器（Multi-Sequence Snowflake）代码示例。 [^4]: 在金融系统中，分布式ID是业务的“数字身份证”——它必须绝对唯一、生成快速、能追溯来源，还要扛住峰值交易压力。 相关问题： 1. 在分布式系统中如何解决雪花算法的时钟回拨问题？ 2. 美团Leaf的号段模式是如何保证高可用性的？ 3. 如何根据业务需求选择合适的分布式ID生成方案？ </think>### 全方面对比分布式ID生成方案 以下从6个维度对比常见分布式ID方案（自增ID、UUID、雪花算法、Leaf等），结合引用资料分析优劣： | **维度** | **自增ID** | **UUID** | **雪花算法** | **美团Leaf(号段)** | **业务字段组合** | |------------------|-------------------------------|----------------------------------|----------------------------------|--------------------------------|------------------------------| | **唯一性** | 单机唯一，分布式冲突[^1] | 全球唯一（128位） | 分布式全局唯一[^4] | 分布式全局唯一[^4] | 依赖业务规则（易冲突）[^1] | | **有序性** | 严格递增 | 完全无序 | 趋势递增（时间戳高位） | 趋势递增（号段连续）[^4] | 部分有序（如含日期） | | **生成效率** | 高（依赖DB） | 极高（本地计算） | 高（本地计算） | 极高（本地批取号段）[^4] | 中（拼接业务字段） | | **存储空间** | 小（8字节） | 大（16字节）[^1] | 小（8字节） | 小（8字节） | 不定（可能较长） | | **分布式适应性** | 弱（需分库分表策略） | 强 | 强（需解决时钟回拨）[^1][^4] | 强（中心服务高可用）[^4] | 弱（业务耦合高） | | **典型缺点** | 扩展性差，暴露数据量[^1] | 索引效率低，存储大[^1] | 时钟回拨导致重复[^3][^4] | 依赖中心服务[^4] | 灵活性低，难维护[^1] | --- ### 关键方案详解 1. **雪花算法优化（应对时钟回拨）** 引用[^3]的多序列号生成器方案，通过多个Worker并行提升性能： ```java public class MultiSequenceSnowflake { private final SnowflakeIdGenerator[] generators; // 多生成器实例 private final AtomicInteger index = new AtomicInteger(0); public long nextId() { int idx = index.getAndIncrement() % generators.length; return generators[idx].nextId(); // 轮询生成 } } ``` - **优势**：利用多核CPU并行生成，吞吐量提升$N$倍（$N$=CPU核心数） - **代价**：WorkerID管理更复杂，时钟回拨风险仍存在[^3][^4] 2. **美团Leaf的金融级实践** 引用[^4]强调金融场景需求： - **号段模式**：批量获取ID区间（如1~1000），客户端本地消费 - **双Buffer机制**：当前号段用尽前异步加载下一号段，消除等待延迟 - **高可用**：通过ZK/ETCD协调服务节点，故障自动切换[^4] --- ### 选型建议（引用[^1][^4]） 1. **单机小规模**：自增ID（简单高效） 2. **分布式高并发**： - 无严格有序需求 → **UUID**（生成快，但存储和索引代价高） - 需趋势有序 → **雪花算法**（注意时钟回拨解决方案[^3]） - 金融等高可用场景 → **Leaf号段模式**（通过中心服务保障）[^4] 3. **业务强定制**：字段组合（如订单ID=商户ID+日期+序列） > **核心公式**（引用[^1]）： > 选型权重 = $k_1 \times \text{唯一性} + k_2 \times \text{性能} + k_3 \times \text{存储成本}$ > 其中$k_i$为业务场景的权重系数，如金融系统$k_1 \gg k_2$[^4] ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值