mysql不使用自增_自增ID有什么坏处？什么样的场景下不使用自增ID？

最新推荐文章于 2025-03-13 19:54:20 发布
最新推荐文章于 2025-03-13 19:54:20 发布
阅读量4.2k 收藏 14
点赞数 2
文章标签： mysql不使用自增
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_29660659/article/details/113970559
版权

大家好，我是IT修真院上海分院第3期学员，一枚正直善良的java程序员，今天给大家分享一下，修真院java任务中的一个知识点：自增ID有什么坏处？什么样的场景下不使用自增ID？

1.背景

对于MySQL中表的主键一般采用id字段自增的形式，不过自增id存在一些问题，在一些场景下是不推荐使用自增ID的。

2.什么是自增ID

自增ID是在设计表时将id字段的值设置为自增的形式，这样当插入一行数据时无需指定id会自动根据前一字段的ID值+1进行填充。在MySQL数据库中，可通过sql语句AUTO_INCREMENT来对特定的字段启用自增赋值 使用自增ID作为主键，能够保证字段的原子性.

3.自增ID有什么好处

在添加一行时无需对自增id列赋值，在添加一行数据时可留空，会自动根据前一字段id值+1填充

单个表中能够唯一标识该字段，保证原子性。在单个表中使用自增ID能够保证主键不重复

4.自增ID有什么坏处

不存在连续性，也就是说若表中存有3行数据，ID字段为1,2,3 那么当删除字段2时就变为1,3，不具有连续性

合并表会出现ID重复的情况，上面说个使用自增ID能够在单个表中保证ID字段唯一，但两个表何为1个表，时不具有这种性质的。

5.什么场景下不使用自增ID

正是因为自增ID的缺点也就是无法在多个表中，或者多个数据库中保持ID主键唯一不重复，所以若是使用分布式数据库以及数据合并的情况下时不能使用自增ID的。

若是能够有其他的字段能作为主键保证唯一性，无需使用自增ID

6.自增ID的替代者UUI

UUID含义是通用唯一识别码 (Universally Unique Identifier)，指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成的API。换句话说能够在一定的范围内保证主键id的唯一性。

7.UUID存在的目的

UUID的目的，是让分布式系统中的所有元素，都能有唯一的辨识信息，而不需要通过中央控制端来做辨识信息的指定。如此一来，每个人都可以创建不与其它人冲突的UUID。在这样的情况下，就不需考虑数据库创建时的名称重复问题。也就完美解决的自增ID的缺点。

今天的分享就到这里啦，欢迎大家点赞、转发、留言、拍砖~

技能树.IT修真院“我们相信人人都可以成为一个工程师，现在开始，找个师兄，带你入门，掌控自己学习的节奏，学习的路上不再迷茫”。

这里是技能树.IT修真院，成千上万的师兄在这里找到了自己的学习路线，学习透明化，成长可见化，师兄1对1免费指导。快来与我一起学习吧~我的邀请码：16318412，或者你可以直接点击此链接：http://www.jnshu.com/login/1/16318412

作者：Himly

PPT地址：PPT

自增ID有什么坏处？什么样的场景下不使用自增ID？_腾讯视频

王骁Albert
关注
MYSQL——数据库的自增id类型
庄小焱
04-17 4481
MySQL 里有很多自增的 id，每个自增 id 都是定义了初始值，然后不停地往上加步长。虽然自然数是没有上限的，但是在计算机里，只要定义了表示这个数的字节长度，那它就有上限。比如，无符号整型 (unsigned int) 是 4 个字节，上限就是 2^32-1。既然自增 id 有上限，就有可能被用完。但是，自增 id 用完了会怎么样呢？
线上MySQL的自增id用完了怎么办？
m0_71777195的博客
07-12 231
MySQL的自增id都定义了初始值，然后不断加步长。虽然自然数没有上限，但定义了表示这个数的字节长度，计算机存储就有上限。比如，无符号整型(unsigned int)是4个字节，上限就是2^32 - 1。那自增id用完，会怎么样？表定义的自增值达到上限后的逻辑是：再申请下一个id时，得到的值保持不变。 mysql> create table t(id int unsigned auto_increment primary key) auto_increment=4294967295; Query OK
mysql在没有设置自增主键会导致如下问题
小民工的博客
09-30 5137
如果不设置自增,插入数据的时候,会将上一条数据被覆盖. SSH中创建实体类时候没有注意细节,导致之后整合插入数据的时候出现该错误,在SSH_DEMO中 personInform类 只添加了主键注解,没有添加自增注解.出现了这个数据覆盖异常. @GeneratedValue(strategy=GenerationType.AUTO) 错误代码: @Id @Column(na
弃用数据库自增ID，曝光一下我自己用到的解决方法
weixin_30537451的博客
01-17 576
　　在平时的项目开发中，我相信有很大一批人都在用这个数据库自增ID，用数据库自增ID有利也有弊。　　　　优点：节省时间，根本不用考虑怎么来标识唯一记录，写程序也简单了，数据库帮我们维护着这一批ID号。　　　　缺点：for example, 在做分布式数据库时，要求数据同步时，这种自增ID就会出现严重的问题，因为你无法用该ID来唯一标识记录。同时在数据库做移植时，也会出现各种问题，总之，对此自增ID...
为什么不推荐使用自增ID？
小李同学的博客
03-13 1002
在MySQL数据库的开发与管理中，自增ID（AUTO_INCREMENT）常常被开发者当作主键生成的默认方案。它的使用简单便捷，只需在创建表时指定字段为自增，数据库便会自动为新插入的记录分配一个唯一且递增的ID。然而，在实际的生产环境，尤其是面对高并发、分布式系统和复杂业务需求时，自增ID却暴露出了诸多弊端。MySQL自增ID虽然在简单场景下具有一定优势，但在高并发、分布式和复杂业务需求的场景中，其局限性日益明显。
数据库id自增长的弊端分析
weixin_41113108的博客
04-24 3291
1、数据导出再导入很可能发生变化，因此并不是所有的表都适合自增长；2、增长是从1开始的，有些数据的id是不可能是个位数；3、分库分表是不能用自增长的。为此我们可以采取以下几种解决方案：1、时间+随机数2、采用redis的incr()方法产生id...
mysql从百万数据中随机查询多条数据，主键id不自增
u012150602的博客
05-12 841
mysql从百万数据中随机查询多条数据，主键id不自增
什么？Mysql不设置主键竟然这么多问题
weixin_42104279的博客
01-13 1465
不创建主键时，使用不了主键索引，查询会进行全表扫描，影响性能插入数据需要生成ROW_ID，而生成的ROW_ID是全局共享的，并发会导致锁竞争，影响性能所以在建表的时候还是要设置主键，无论表设计有无合适的唯一字段，都需要设置一个主键，提高性能的同时也是一种好的习惯，对于后续的拓展以及表之间关联都有一定的拓展性。否则，数据量大了，坑的可就是自己了。
自增ID有什么坏处？什么样的场景下不使用自增ID？
IT修真院：初学者转行到互联网的聚集地
05-20 9263
这里是修真院后端小课堂，每篇分享文从 【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】 八个方面深度解析后端知识/技能，本篇分享的是： 【自增ID有什么坏处？什么样的场景下不使用自增ID？】 1.背景介绍 在MySQL中，数据表的主键一般采用id字段自增的形式。使用自增ID给我们带来不少便捷，但也有不少坏处。 2.知识...
MySQL中的自增主键 ID自增到最大，使用完id会发生什么，怎么办？
Agly_Charlie的博客
07-21 6677
文章目录背景测试过程创建表，自增ID场景一：测试自增ID已经达到最大值场景二：测试自增ID即将达到最大值总结解决方案扩展扩展1：修改字段的数据类型，建议使用modify 用法扩展2：Alter table的底层原理 背景 之前的学习和实践上了解到的是： SQL插入异常，主键冲突错误，因为自增ID达到上限后，再申请时它的值不会改变，继续插入数据会导致报主键冲突错误 /* SQL Error (1062): Duplicate entry '2147483647' for key 'PRIMARY' */
mysql insert ingore_MySQL在INSERT IGNORE未新增记录时避免AUTO_INCREMENT自增
weixin_42300113的博客
02-07 512
在MySQL5.7中做INSERT IGNORE时发现, 即使INSERT未成功执行, 表的自增主键却自动加1了, 在某些情况下需要避免这种行为. 需要修改的变量是innodb_autoinc_lock_mode, 将其设为0后, 在INSERT未成功执行时不会自增主键.innodb_autoinc_lock_mode在MySQL各版本的默认值根据MySQL官方手册的说明:There are t...
mysql在定义表时 可以不指定主键_数据库设计时，每个表要不要都设置自增主键ID！（转）...
weixin_39599046的博客
01-19 2099
本文的目标就是要确认那些使用了主键，却混淆了主键的本质而造成的一种反模式。一、确立主键规范每个了解数据库设计的人都知道，主键对于一张表来说是一个很重要，甚至必需的部分。这确实是事实，主键是好的数据库设计的一部分。主键是数据库确保数据行在整张表唯一性的保障。它是定位到一条记录并且确保不会重复存储的逻辑机制。主键也同时可以被外键引用来建立表与表之间的关系。难点是选择那一列作为主键。大多数表中的每个属性...
RSA加密-防止自增id被遍历
qq_38895905的博客
12-22 1635
文章目录非对称加密优点：缺点：RSA 算法demo加密demo入口解密demo 非对称加密 非对称加密需要两个密钥：公钥 (publickey) 和私钥 (privatekey)。公钥和私钥是一对，如果用公钥对数据加密，那么只能用对应的私钥解密。如果用私钥对数据加密，只能用对应的公钥进行解密。因为加密和解密用的是不同的密钥，所以称为非对称加密。 优点： 安全 缺点： 加密和解密花费时间长、速度慢,只适合对少量数据进行加密 RSA 算法 RSA算法是一种典型的非对称加密的算法 具体信息安利一篇博客 htt
ID字段不采用数据库自增长的几点理由
HiSpring的专栏
02-13 2429
      近日在做一个小程序，最初采用了 SqlServer 数据库，后来为了便于部署，转而采用了 Firebird 嵌入式数据库。在重构代码转到 Firebird 的过程中，对“数据实体的数据表的ID字段是否应该使用自增长字段”这个问题做了一些思考，在此做一些总结。       对于是否应该使用自增长的ID字段的问题，个人的观点是应该根据自己的项目情况考虑，谨慎使用。要“谨慎”是因为这
MySQL：自增主键VS非自增主键
OceanStar的博客
05-29 3598
使用自增主键的好处 每次插入新的记录，记录就会顺序的添加到当前索引节点的后续位置，当一页写满，就会自动开辟一共新的页。 使用非自增主键坏处 由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置，此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。 总结
一文弄清：mysql自增表插入数据时，Id不连续问题
ayupch的博客
09-29 8066
今天查看数据库时，发现id设置了auto_increment，但是，数据库中id是不连续。正好趁着这个机会总结一下mysql常用的插入语句（insert into、insert ignore into、insert into … on duplicate key update)
mysql何时选择自增id？何时不选？
Jeff__Chou的博客
03-10 2869
mysql何时选择主键，何时不选择主键
MySQL自增ID用完了会怎么样？
weixin_38155824的博客
02-22 630
这个问题要区分建表时是否有设置主键的情况。 有设置主键 建表时有设置主键的情况下，当ID超过该主键类型的最大限制，会报主键冲突错误。 在 MySQL 中，一般会把主键设置成 int 型。而 MySQL 中 int 型占用 4 个字节，作为有符号位的话范围就是 [-231,231-1]，也就是[-2147483648,2147483647]；无符号位的话最大值就是 2^32-1，也就是 4294967295。 没设置主键 建表时没有设置主键的情况下，InnoDB 会自动帮你创建一个不可见的、长度为 6
MySQL:数据库自增 ID 用完了会咋样？
m0_69519298的博客
05-05 3080
01 前言 数据库中的自增 ID 用完了该怎么办？ 这个问题其实可以分为有主键 & 无主键两种情况回答。 先上张脑图： 02 有主键 如果你的表有主键，并且把主键设置为自增。 在 MySQL 中，一般会把主键设置成 int 型。而 MySQL 中 int 型占用 4 个字节，作为有符号位的话范围就是 [-231,231-1]，也就是[-2147483648,2147483647]；无符号位的话最大值就是 2^32-1，也就是 4294967295。 下面以有符号位创建一张表： CREATE T
mysql自增起始值为什么超大
最新发布
04-11
### MySQL 自增字段初始值过大的原因 MySQL 中 `AUTO_INCREMENT` 字段的初始值可能变得非常大，主要原因可以归纳为以下几个方面： - **数据迁移**：在将其他数据库的数据迁移到 MySQL 时，如果源数据库中的自增字段已经达到了较大的数值，则目标表的 `AUTO_INCREMENT` 值会被设置为对应的最大值加一[^1]。 - **手动设置**：开发人员为了满足某些特殊业务需求，可能会通过 SQL 显式地调整 `AUTO_INCREMENT` 的初始值。例如，在创建表时指定较大的初始值或者通过 `ALTER TABLE` 修改现有表的自增属性[^4]。 - **数据表重建**：当重新构建一张表并希望保留原有数据结构及其特性时，新的表会继承原表最后使用的 `AUTO_INCREMENT` 值，这可能导致初始值较大[^1]。 #### 设置方法 对于需要调整或初始化 `AUTO_INCREMENT` 值的情况，有多种方式实现这一操作： - 使用 `ALTER TABLE` 语句来更改已存在表的自增起点。例如： ```sql ALTER TABLE table_name AUTO_INCREMENT = desired_value; ``` 这里的 `desired_value` 即为目标初始值[^3]。 - 创建新表时直接设定 `AUTO_INCREMENT` 属性。如下所示的例子展示了如何定义一个新的表并将它的 `AUTO_INCREMENT` 起始点设为 100： ```sql CREATE TABLE example_table ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(255), PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=100 DEFAULT CHARSET=utf8; ``` 此外还可以利用全局变量控制增量行为，比如通过修改 `@@auto_increment_offset` 和 `@@auto_increment_increment` 来影响多个服务器实例间的同步机制[^2]。 ### 总结 综上所述，MySQL 表中 `AUTO_INCREMENT` 初始值变大的现象主要源于实际应用过程中的各种因素作用所致；而针对不同场景下的具体需求则提供了灵活多样的解决方案供使用者选择实施。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值