数据库主键到底是用自增长(INT)好还是UUID好

数据库主键到底是用自增长(INT)好还是UUID好


之前在参加长沙互联网大会的时候问过微信DBA一个问题,数据库主键到底是用自增长好还是UUID好?DBA回答:自增长好,因为自增长有占用空间小、索引快等特点。但这一定是最好的吗?最近在做一个项目刚好也遇到了同样纠结的问题,其实这个问题我已经查过很多资料也问过很多人了,最后总结归纳下,仅供大家参考。

其实针对使用自增长还是UUID,大家讨论最多的就是速度和存储空间,这里我加入了安全性和分布式,具体对比如下:

使用自增长做主键的优点:
1、很小的数据存储空间
2、性能最好
3、容易记忆
使用自增长做主键的缺点:
1、如果存在大量的数据,可能会超出自增长的取值范围
2、很难(并不是不能)处理分布式存储的数据表,尤其是需要合并表的情况下
3、安全性低,因为是有规律的,容易被非法获取数据
使用GUID做主键的优点:
1、它是独一无二的,出现重复的机会少
2、适合大量数据中的插入和更新操作,尤其是在高并发和分布式环境下
3、跨服务器数据合并非常方便
4、安全性较高
使用GUID做主键的缺点:
1、存储空间大(16 byte),因此它将会占用更多的磁盘空间
2、会降低性能
3、很难记忆

结合每个项目的实际应用,我们应该怎么选择呢?如下:

1、项目是单机版的,并且数据量比较大(百万级)时,用自增长的,此时最好能考虑下安全性,做些安全措施。
2、项目是单机版的,并且数据量没那么大,对速度和存储要求不高时,用UUID。
3、项目是分布式的,那么首选UUID,分布式一般对速度和存储要求不高。
4、项目是分布式的,并且数据量达到千万级别可更高时,对速度和存储有要求时,可以用自增长。

现在有人就会问了,为什么不直接用第4种方案,它满足前面三种方案的所有要求?就是因为在用自增长时分布式处理会很复杂(具体方案可以百度),在资源有限的情况可以采用前面三种简单的实现方案。

那么,为什么一定要使用自增长或UUID作为数据库主键呢?有没有更好的解决方案呢?肯定有:snowflake

其实大部分项目可以使用twitter的snowflake来生成主键,snowflake生成的主键就是介于自增长和UUID之间的一种主键(存储空间小、速度快、分布式、时间序列)。据说snowflake每秒能够产生26万个ID,最多可以部署在1024个节点上,研发团队可以将snowflake作为底层的数据库主键工具类供团队成员使用。



转载至:  http://www.yyjjssnn.cn/articles/754.html     感谢博主分享
<think>好的,我现在需要帮助用户解决关于数据库主键是否必须自增长以及主键使用规范的问题。首先,我要回顾用户的问题,确保我理解正确。用户想知道主键是否必须设置为自增长,同时想了解主键的使用规范和应用场景。接下来,我需要结合之前提供的引用内容来构建回答。引用中提到了复合主键自增长的特点、主键的作用(唯一且非空),以及不同场景下的主键选择策略,比如自增ID、雪花算法、GUID等。这些信息都是回答用户问题的重要依据。首先,回答“主键是否必须自增长”。根据引用[2],主键的主要作用是唯一且非空,但并没有强制要求自增长。引用[4]也提到,自增ID适合单体应用或简单分布式系统,而分布式系统可能更适合雪花算法或GUID。因此,结论应该是主键不一定需要自增长,取决于具体场景。 接下来,主键的使用规范需要涵盖几个方面:唯一性、非空性、选择合适的数据类型、是否使用复合主键、业务相关性等。引用[1]中的例子展示了复合主键的使用,引用[3]说明不连续的主键ID并不影响功能性和性能,所以可以提到连续性不是必须的。然后,应用场景部分需要区分不同类型的系统,比如单体应用、分布式系统,以及是否需要全局唯一性。引用[4]详细讨论了不同场景下的选择,这里需要总结这些内容,给出用户清晰的指导。另外,用户可能关心自增长主键的优缺点。根据引用[3],自增ID可能出现不连续的情况,但这是正常现象。优点包括简单高效、索引效率高,缺点则是在分布式系统中可能成为瓶颈,以及暴露业务信息。最后,生成相关问题需要考虑用户可能的后续疑问,比如主键设计原则、自增主键的优缺点、复合主键的应用场景、分布式系统的主键选择等。这些问题可以帮助用户进一步探索主题。 需要确保回答结构清晰,分点列出,使用中文,并正确应用引用标注。同时,检查是否有遗漏的引用内容,确保回答的准确性和全面性。</think>### 主键是否必须自增长及使用规范 #### 一、主键是否必须自增长? **不需要**。主键的核心作用是**唯一标识记录**并保证**非空性**,是否自增长取决于具体业务场景和系统设计需求[^2][^4]。 - **自增主键**适用于单体应用或简单系统,能简化开发并提升索引效率[^3][^4]。 - **非自增主键**(如GUID、雪花算法生成的ID)更适合分布式系统,可避免单点性能瓶颈并保证全局唯一性[^4]。 #### 二、主键使用规范 1. **唯一性与非空性** 主键字段必须唯一且不允许为空,确保每条记录可被唯一标识[^2]。 2. **数据类型选择** - 优先选择**数值类型**(如`INT`、`BIGINT`),因其索引效率高[^4]。 - 若需全局唯一性,可使用`UUID`或`VARCHAR`存储哈希值[^4]。 3. **复合主键** 当单列无法唯一标识记录时,可通过多列组合定义复合主键。例如: ```sql CREATE TABLE tt14 ( id INT UNSIGNED, course CHAR(10) COMMENT '课程代码', score TINYINT UNSIGNED DEFAULT 60 COMMENT '成绩', PRIMARY KEY(id, course) -- 复合主键 ); ``` 适用于多对多关系或业务规则复杂的场景[^1][^2]。 4. **业务相关性** 若业务本身存在唯一标识符(如订单号、身份证号),可直接将其设为主键,避免冗余字段[^4]。 5. **连续性非强制** 主键值不要求连续,仅需保证唯一性。自增ID的不连续现象是正常的,不影响功能与性能[^3]。 #### 三、自增主键的优缺点 | **优点** | **缺点** | |-------------------------|--------------------------| | 简单高效,减少开发复杂度 | 分布式场景下易成性能瓶颈 | | 索引效率高(顺序写入) | 可能暴露业务规模(如订单量) | | 适合OLTP高频插入场景 | 分库分时需额外处理 | #### 四、主键设计场景建议 1. **单体应用** 优先使用自增主键(如`AUTO_INCREMENT`),兼顾效率与简洁性[^4]。 2. **分布式系统** - **跨数据中心**:使用雪花算法(Snowflake)生成全局唯一ID[^4]。 - **高扩展需求**:采用GUID(如UUID),牺牲部分存储空间换取唯一性[^4]。 3. **业务强关联** 直接使用业务字段(如ISBN号、学号)作为主键,减少冗余[^4]。 ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值