为什么不建议用字符串或者uuid做数据库主键

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

#数据库 #database

UUID作为唯一标识符，具备本地生成的优势，避免了对数据库的依赖。然而，其长度过长，占用空间大，作为主键时性能不佳，且缺乏有序性，影响B+树索引的写操作效率。尽管如此，在生成文件名或编号时，UUID仍是一个不错的选择。

UUID

好处就是本地生成，不要基于数据库来了；不好之处就是，UUID 太长了、占用空间大，作为主键性能太差了；更重要的是，UUID 不具有有序性，会导致 B+ 树索引在写的时候有过多的随机写操作（连续的 ID 可以产生部分顺序写），还有，由于在写的时候不能产生有顺序的 append 操作，而需要进行 insert 操作，将会读取整个 B+ 树节点到内存，在插入这条记录后会将整个节点写回磁盘，这种操作在记录占用空间比较大的情况下，性能下降明显。

适合的场景：如果你是要随机生成个什么文件名、编号之类的，你可以用 UUID，但是常规业务不建议主键用 UUID 的。当然，万事无决定，毕竟还有分布式和雪花算法的概念

UUID 作为 Mysql 的主键优劣分析
java专栏
04-08 748
UUID 作为 MySQL 的主键有其独特的优势，但也存在一些明显的劣势。考虑到UUID的劣势，有些系统采用折衷方案来优化性能。索引效率：由于UUID的随机性，它们的数据分布会非常稀疏，这可能导致数据库在查询时需要更多的磁盘I/O操作，降低了索引的效率。UUID（Universally Unique Identifier，通用唯一识别码）作为 MySQL 数据库的主键，有其独特的优势和劣势。易于迁移和合并：由于UUID的唯一性，数据可以在不同的数据库或系统之间轻松迁移和合并，无需担心主键冲突。
使用UUID作为数据库主键产生的问题及解决方案
四问四不知的博客
10-03 5351
序言 看了b站IT老齐的架构三百讲的其中一个短视频，有所体会并记录一下。视频中所讲的财经部门使用的UUID主键，在日终结算时出现磁盘的IO异常，导致应用出现高延迟。最后发现是UUID的问题，UUID作为主键在数据进行插入的时候对于系统的压力是非常大的。 UUID（Universally Unique Identifier）介绍 UUID结构如上图所示，比如7bf13c38-00a1-484e-b1e2-80c1ab8e754c，作为唯一标识符，类似网卡上的MAC地址。 UUID的生成方.
mysql invalid uuid_我为什么不建议开发中使用UUID作为MySQL的主键
weixin_39915210的博客
01-27 600
我是少侠露飞。学习塑造人生，技术改变世界。引言我在之前一篇博客专门介绍了MySQL聚簇索引和非聚簇索引，附传送门：【享学MySQL】系列：MySQL索引的数据结构，索引种类及聚簇索引和非聚簇索引简单来说，就是我们设计表的时候，基本都会人为设定一个主键，这就是聚簇索引(如果没有设定主键，MySQL会选择非空不唯一的字段作为聚簇索引，如果依然没有，则MySQL会选择自己隐藏列row_id作为聚簇索引)...
为什么不推荐使用 UUID 作为主键
modelsetget的博客
06-26 884
为什么不推荐使用 uuid 作为 mysql 主键
为什么在 MySQL 中主键不应该使用随机字符串？
quanzhan_King的博客
04-25 667
1. 为什么不用 UUID经过上篇文章的介绍，我们知道在 MySQL 中，主键索引就是聚簇索引，MySQL 表中的数据是根据主键值聚集在一起的，聚簇索引是一棵 B+Tree，这棵树中的数据是有序的。所以，如果我们使用 UUID 字符串作为主键，那么就会导致每次数据插入的时候，都需要在 B+Tree 中寻找到适合它自己的位置，找到之后就有可能要挪动后面的节点（就像在数组中插入一条记录），挪动后面的节点，就有可能涉及到页分裂，插入效率就会降低。另一方面，在非聚簇索引中，叶子结点保存的
为什么不推荐用 UUID 作为 Mysql 的主键
weixin_42104279的博客
01-27 549
在分库分表的情况下，插入的 id 都是专门的 id 服务生成的，如果要严格按照自增的话，那么一般就会通过 redis 来生成，按批次去获得，比如一次性获取几百个，用完了再去获取，但是如果 redis 服务挂了，功能就完全没法用了，那有么有不依赖与第三方组件的方法呢？，那么它产生的 id 每次都比前次要大，所以每次都会将数据家在 B+ 树的尾部，B+ 树的叶子节点本质是双向链表，查找它的首部和尾部，**时间复杂度 O(1)**，如果此时最末尾的数据也满了，那创建个新的页就好。大家好，我是銘，全栈开发程序员。
面基：为什么不推荐用UUID作为主键
qq_37679639的博客
03-31 1228
UUID作为主键，缺点是存储空间大、索引碎片化、查询性能差。
深入分析mysql为什么不推荐使用uuid或者雪花id作为主键
09-14
这里我们将深入探讨为什么MySQL不建议使用这两种类型的ID，并通过实例和程序测试来展示它们之间的性能差异。 首先，让我们理解UUID（Universally Unique Identifier）和雪花ID（Snowflake ID）。UUID是一个128位的...
web开发工具之：一、UUID的介绍，java如何产生UUID，作为数据库的主键和加密算法的盐
冯安晨
01-16 699
现在web开发中，很多使用UUID作为主键和加密的盐的，其实很简单，这里学习和介绍一下。
Java 中将 UUID 存储为 Base64 字符串
04-28
### Java 中将 UUID 存储为 Base64 字符串 #### 一、引言 在软件开发领域，尤其是在处理大规模分布式系统时，UUID（通用唯一标识符）因其全局唯一性而广泛应用于各种场景，例如作为数据库记录的主键、会话标识等。...
为什么官方不建议使用uuid做MySQL主键
wufaqidong1的博客
07-19 3296
本篇博客首先从开篇的提出问题,建表到使用jdbcTemplate去测试不同id的生成策略在大数据量的数据插入表现，然后分析了id的机制不同在mysql的索引结构以及优缺点，深入的解释了为何uuid和随机不重复id在数据插入中的性能损耗，详细的解释了这个问题。在实际的开发中还是根据mysql的官方推荐最好使用自增id，mysql博大精深，内部还有很多值得优化的点需要我们学习。本篇博客demo地址httpshttpshttpshttpshttpshttpshttpshttpshttps。...
数据库主键设计之为什么不推荐使用数据库自增主键和UUID，雪花算法有何潜在问题？
最新发布
qq_50124714的博客
09-12 1062
对比分析数据库自增主键、UUID和雪花算法三种ID生成方案的优缺点。
UUID做主键,优点,缺点!
心猿问道的博客
05-26 1809
优点： 能够保证独立性，程序可以在不同的数据库间迁移，效果不受影响。 保证生成的ID不仅是表独立的，而且是库独立的，这点在你想切分数据库的时候尤为重要。 缺点： 比较占地方，和INT类型相比，存储一个UUID要花费更多的空间。 使用UUID后，URL显得冗长，不够友好。 ...
使用自增ID主键和UUID作为主键的优劣比较
Buns.的博客
12-03 7553
mysql不要用uuid用自增主键，自增主键效率高innodb的索引特性导致了自增id做主键是效率最好的 测试： 1、准备表以及数据 UC_USER，自增ID为主键，表结构类似如下： CREATE TABLE `UC_USER` (  `ID` bigint(20) NOT NULL AUTO_INCREMEN...
数据库主键采用整型还是字符串？
zdb_2457的博客
06-04 3669
整型的好处：速度快，自增方便。 字符串的好处：自定义方便。 主键索引会先存入内存区，如果用字符串占用内存会比较大。建议采用整型。
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（从百万到千万表记录测试）
LWT_博客
08-27 1417
一个开发同事做了一个框架，里面主键是uuid，我跟他建议说mysql不要用uuid用自增主键，自增主键效率高，他说不一定高，我说innodb的索引特性导致了自增id做主键是效率最好的，为了拿实际的案例来说服他，所以准备做一个详细的测试。 作为互联网公司，一定有用户表，而且用户表UC_USER基本会有百万记录，所以在这个表基础上准测试数据来进行测试。 测试过程是目前我想到的多方位的常用的几种类型的sql进行测试，当然可能不太完善，欢迎大家留言提出更加完善的测试方案或者测试sql语...
数据库 表中主键字符串通过函数取值
lijunjie818的博客
11-29 741
如果项目中有特殊要求，表的主键id用varchar类型，那么自增方式只能通过函数来解决。思路就是在函数中定义开始值和最大值，如果通过参数在某表中查无数据就赋值1，有数据就加一，另给该id做了类似加密 首先需要定义表来存放参数 ，记录当前数据 tbl_base_seq 其次定义函数fun_create_id BEGIN DECLARE cRES_ID varchar(32);#返回
【跳槽面试】使用 int 做 primary key 和使用 string 有什么优劣？
技术分享
01-20 1472
选择使用整数还是字符串作为主键取决于具体的应用场景和需求。在大多数情况下，如果性能是一个关键因素，并且不需要在主键中存储描述性信息，那么使用整数类型的主键是一个更好的选择。然而，在某些情况下，如果需要在主键中包含更多信息，或者可读性和灵活性更加重要，那么使用字符串类型的主键可能更合适。欢迎加入我们的聊天群，这里有专业大佬为你提供有价值的建议和指导！如果您喜欢这篇文章，请点击右下角的。
浅谈 UUID 生成原理及优缺点
BASK2312的博客
06-09 3485
UUID 是一套用于生成全局唯一标识符的标准，具有唯一性、随机性等特性，可以在分布式系统中使用。UUID 的生成方式有多种，其中最为常用的是基于算法的 UUID 生成方式和基于硬件的 UUID 生成方式。UUID 在数据库主键、分布式系统、日志跟踪和安全领域等方面有广泛的应用。虽然 UUID 具有很多优点，但也存在一些缺点，比如占用空间大、不易读懂、不适合顺序访问和算法复杂等。综合来看，UUID 是一种非常有用的标识符生成方式，在实际开发中应根据具体情况选择合适的 UUID 生成方式。
uuid和自增id做主键哪个好，为什么
09-01
### 自增ID做主键 #### 优点 - **性能高**：自增ID是顺序增长的，在插入新记录时，数据库可以很方便地将新记录追加到已有数据的末尾，减少了页分裂和数据移动的情况，从而降低了IO开销。对于InnoDB存储引擎，数据会按照主键进行排序，自增ID的有序性使得数据存储更加紧凑，提高了存储和查询效率[^1]。 - **占用空间小**：通常自增ID使用整数类型（如INT、BIGINT），占用的存储空间相对较小，相比之下，UUID需要更多的存储空间。 - **索引效率高**：由于自增ID是有序的，索引的维护和查找效率更高。数据库在进行范围查询、排序等操作时，使用自增ID作为主键可以更快地定位和访问数据。 #### 缺点 - **插入限制**：自动增长特性使得在手动插入指定ID的记录时变得麻烦。当系统与其他系统集成，需要进行数据导入时，很难保证原系统的ID不发生主键冲突。特别是在新系统上线，新旧系统并行且数据库异库异构，需要双向同步时，自增主键会带来很大困扰。在系统集成或割接时，如果新旧系统主键类型不同，修改主键数据类型会导致关联表的修改，后果严重。若想在老数据主键前统一加字符标识区分新老数据，自动增长的数字型主键也面临挑战[^2]。 - **分布式系统问题**：在分布式系统中，多个节点可能同时插入数据，自增ID难以保证全局唯一性，需要额外的机制来协调。 ### UUID做主键 #### 优点 - **全局唯一性**：UUID是基于特定算法生成的唯一标识符，在全球范围内都具有唯一性，无需担心主键冲突的问题。在分布式系统中，多个节点可以独立生成唯一的ID，方便数据的合并和同步。 - **数据导入和集成方便**：由于UUID的唯一性，在数据导入、系统集成或割接时，无需担心主键冲突的问题，避免了自增ID在这些场景下的困扰。 #### 缺点 - **性能低**：UUID是无序的，在插入新记录时，会导致数据存储的分散，增加了页分裂和数据移动的概率，从而产生较大的IO压力。对于InnoDB存储引擎，使用UUID作为主键会使得数据存储不紧凑，降低了存储和查询效率[^1]。 - **占用空间大**：UUID通常使用128位的字符串表示，占用的存储空间比整数类型的自增ID大，会增加数据库的存储成本。 - **索引效率低**：由于UUID的无序性，索引的维护和查找效率较低。数据库在进行范围查询、排序等操作时，使用UUID作为主键会导致性能下降。 综上所述，选择自增ID还是UUID做主键取决于具体的应用场景。如果是单机系统，数据插入以顺序为主，对性能要求较高，且不需要考虑全局唯一性，那么自增ID是一个较好的选择；如果是分布式系统，需要保证数据的全局唯一性，且对数据插入的顺序没有严格要求，那么UUID更适合。 ```sql -- 创建使用自增ID做主键的表 CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50), email VARCHAR(100) ); -- 创建使用UUID做主键的表 CREATE TABLE products ( id CHAR(36) PRIMARY KEY DEFAULT UUID(), name VARCHAR(50), price DECIMAL(10, 2) ); ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值