使用数据库自增ID弊端

最新推荐文章于 2024-07-10 16:37:18 发布
最新推荐文章于 2024-07-10 16:37:18 发布
阅读量3.5k 收藏 2
点赞数 1
分类专栏： 后端 文章标签： 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiaolulululululu/article/details/91446459
版权
  1. 导入旧数据时，可能会ID重复或ID变化，导致导入失败。
  2. 分布式架构，分库分表，无法实现全局ID唯一。
  3. 增长是从1开始的，无法处理统一为统一格式。
OxygenBling
关注
专栏目录
Mysql学习总结（77）——温故Mysql数据库开发核心原则与规范
科技D人生
09-12 4446
一、核心原则 1、尽量不在数据库做运算 俗话说：别让脚趾头想事情，那是脑瓜子的职责。作为数据库开发人员，我们应该让数据库多做她所擅长的事情。尽量不在数据库做运算，复杂运算移到程序端CPU，尽可能简单应用MYSQL。 举例：在mysql中尽量不要使用如：md5()、Order by Rand()等这类运算函数 2、尽量控制单表数据量 大家都知道单表数据量过大后会影响数据查询效率，严重情况下...
关于MySQL自增ID的一些小问题总结
12-16
下面这几个小问题都是基于 InnoDB 存储引擎的。 1. ID最大的记录删除后，新插入的记录ID是什么 例如当前表中有ID为1,2,3三条记录，把3删除，新插入记录的ID从哪儿开始？ 答案： 从4开始。 实验 创建表 tb0，ID自增： create table tb0(id int unsigned auto_increment primary key); 插入3条记录： insert into tb0 values(null); 删除ID为3的记录： delete from tb0 where id=3 查看当前自增值： show create table tb0; # 结
数据库id自增长的弊端分析
weixin_41113108的博客
04-24 3249
1、数据导出再导入很可能发生变化，因此并不是所有的表都适合自增长；2、增长是从1开始的，有些数据的id是不可能是个位数；3、分库分表是不能用自增长的。为此我们可以采取以下几种解决方案：1、时间+随机数2、采用redis的incr()方法产生id...
在数据库设计中，选择自增 ID 还是 GUID？这篇文章讲清楚
最新发布
炫爱小七的博客
07-10 222
在数据库设计中，选择自增 ID 还是 GUID？这篇文章讲清楚
mysql自增值的坑_mysql使用自增id遇到的坑
weixin_29224309的博客
01-28 286
背景最近在做一个项目，给APP提供接口，用户认证机制采用了JWT(JSON Web Token)。项目开发完之后，给用户测试(删档测试)，测试完之后，清空了数据库里的数据，之后又其他用户注册了。然后问题就来了，此时用户id为1的用户和以前为1的用户已经不是同一个用户了。但是APP内的token没清除，以前用户的id为1的用户进入APP后显示的是当前用户id为用户对应的信息。解决方案使用UUID，其...
oralce 同步数据的 id 自增的坑
wangxj_2017的博客
08-16 240
记录一下工作中遇到的问题，用的数据库是oralce。 解决办法：去掉实体的上的 @GeneratedValue(strategy= GenerationType.AUTO) 描述：跨库同步两张表的数据，从A库将数据同步到B库中 tableA表和tableB表。其中tableB的要求ID 自增。我先找到了 tableB 表中最大的ID ，假设为 5000，接下来将数据同步到tableB表。结果直接报错了，talebB 中 id 已存在。 主要代码如下： xxxx.setId(5000+i)
数据库自增ID会一直自增下去嘛？
正_函数的博客
07-19 650
咱们先回答这个问题，不可以。首先，我们得知道主键其实分为两类，第一类就是自己定义的主键，第二类就是系统为我们自动创建的主键。先看第一类，也就是我们自己显示定义的自增长主键，像下面这样 这里我们以int类型来说，int的最大值为21亿左右（2^31-1），假设自增初始值从0开始计算，增量为1，0、1、2、3、4...，对于小型业务来说，大概率是达不到21亿的，但是对稍微大一点的业务来说，是比较容易达到21亿的。也就是说，这个主键已经封顶了，它已经达到了int的最大值，那么继续往里面插入数据会怎么样呢？我可
自增ID有什么坏处？什么样的场景下不使用自增ID？
IT修真院：初学者转行到互联网的聚集地
05-20 9164
这里是修真院后端小课堂，每篇分享文从 【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】 八个方面深度解析后端知识/技能，本篇分享的是： 【自增ID有什么坏处？什么样的场景下不使用自增ID？】 1.背景介绍 在MySQL中，数据表的主键一般采用id字段自增的形式。使用自增ID给我们带来不少便捷，但也有不少坏处。 2.知识...
全局唯一递增的id_常见的生成全局唯一id有哪些？他们各有什么优缺点？
weixin_39897746的博客
12-18 435
分布式系统中全局唯一id是我们经常用到的，生成全局id方法由很多，我们选择的时候也比较纠结。每种方式都有各自的使用场景，如果我们熟悉各种方式及优缺点，使用的时候才会更方便。下面我们就一起来看一下常见的生成全局唯一id的方法本文主要讨论常见的生成全局唯一id有哪些？他们各有什么优缺点？1. 使用数据库自动增长序列实现使用数据库的自动增长来实现，算是常见最简单的解决方案，数据库内部可以确保生成id的唯...
分布式 ID 生成系统 Leaf 的设计思路，源码解读
m0_71777195的博客
11-29 960
ID 最大的特点是唯一而分布式 ID，就是指分布式系统下的 ID，它是全局唯一的。号段模式Snowflake模式看完上面两种模式，我觉得两种模式都有它适用的场景，号段模式更适合对内使用（比如 用户ID），而如果你这个 ID 会被用户看到，暴露出去有其他风险（比如爬虫恶意爬取等），那就得多斟酌了，。而订单号 就更适合用 snowflake 模式。分布式ID 的特点全局唯一趋势递增（有序一直很重要，粗略有序还是严格有序就看情况了）可反解（可选）信息安全（可选）
利用mysql事务特性实现并发安全的自增ID示例
12-15
项目中经常会用到自增id，比如uid，最简单的方法就是用直接用数据库提供的AUTO_INCREMENT，但是如果用户量非常大，几千万，几亿然后需要分表存储的时候呢，这种方案就搞不定了，所以最好有一个全局的自增ID的生成器，不管是否分表，都能从生成器中获取到全局自增的ID。 实现方法应该有很多，不过所有的方案都需要解决一个问题，就是保证在高并发的情景下，数据获取依然正确，每次获取的ID都不会重复。 这里我分享两种利用mysql的innodb的事务特性来实现的方案，一种是实现过了的，另一种没有试验过，不过应该也能走的通。 先介绍第一种，在数据库中单独设置一张表，来存储ID，表有两个字段，一个是种类
RSA加密-防止自增id被遍历
qq_38895905的博客
12-22 1453
文章目录非对称加密优点：缺点：RSA 算法demo加密demo入口解密demo 非对称加密 非对称加密需要两个密钥：公钥 (publickey) 和私钥 (privatekey)。公钥和私钥是一对，如果用公钥对数据加密，那么只能用对应的私钥解密。如果用私钥对数据加密，只能用对应的公钥进行解密。因为加密和解密用的是不同的密钥，所以称为非对称加密。 优点： 安全 缺点： 加密和解密花费时间长、速度慢,只适合对少量数据进行加密 RSA 算法 RSA算法是一种典型的非对称加密的算法 具体信息安利一篇博客 htt
HTML中的id属性最好不要使用数字命名
weixin_30906701的博客
02-07 642
博主今天在练习javascript的时候，用<input>写了一个按钮，然后再用css定义样式。为了节省时间所以就直接用“01”来定义这个标签的id。结果无论怎么写、怎么检查，都加载不出来之前定义的样式。然后不甘于此，一定要弄清为什么。于是便在W3C官网详细阅读了html规范。 id = ID A unique identifier for the element. ...
技术分享 | 关于 MySQL 自增 ID 的事儿
ActionTech的博客
01-13 2150
作者：贲绍华 爱可生研发中心工程师，负责项目的需求与维护工作。其他身份：柯基铲屎官。 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 当我们使用 MySQL 进行数据存储时，一般会为一张表设置一个自增主键，当有数据行插入时，该主键字段则会根据步长与偏移量增长（默认每次+1）。 下文以 Innodb 引擎为主进行介绍，使用自增主键的好处有很多，如：索引空间占比小、范围查询与排序都友好、避免像 UUID 这样随机字符串带来的页分裂问题等… 一、自增ID是.
分享个java线程安全，自增主键id的类AtomicLong
过天的专栏
04-24 4300
线程安全 自增的类 AtomicLong seq = new AtomicLong(0); seq.incrementAndGet()
数据库id使用数字自动累加还是使用uuid好？
07-12 1681
又碰到一个小白问题。数据库id使用数字自动累加还是使用uuid好？这是要分情况的：1、先要弄清楚这两种id的区别。 数据库id用数字优点：有利于排序，而且肉眼看起来会比较舒服；自动累加，可以计算。缺点：有上限，一般用int型的话好比较好记，如果用long型的话记起来也会比较费劲。缺点里面要命的是他的上限问题。如果超过数据表的数据是无限的，那就不要用，否则将来会出麻烦。 数据库id用uuid优点：重复几率很小，几乎不可能，算出来的32位长度的uuid是根据时间和本机信息加密出来的，所以很难重复;
【数据库】自增ID有什么坏处？什么样的场景下不使用自增ID？
DreamSun的博客
06-01 3665
在MySQL中，数据表的主键一般采用id字段自增的形式。使用自增ID给我们带来不少便捷，但也有不少坏处，在一些场景下是不推荐使用自增ID的。自增ID是在设计表时将id字段的值设置为自增的形式，这样当插入一行数据时无需指定id会自动根据前一字段的ID值+1进行填充。在MySQL数据库中，可通过sql语句AUTO_INCREMENT来对特定的字段启用自增赋值 使用自增ID作为主键，能够保证字段的原子性.根据自己项目实际情况来定！！！没有一套规定的方案适合任何一个系统。分布式唯一 ID 的 8 种生成方案。
mysql 自增长ID字段丢失问题
weixin_43896807的博客
06-24 1245
mysql 自增长ID字段丢失问题分析
数据库连接池：直接连接的弊端与优化
"本文主要探讨了使用数据直接连接的缺点，并提到了数据库连接池的概念，同时穿插介绍了网站项目设计实训中的验证码生成原理和技术细节。" 在开发Web应用程序时，数据库连接管理是一个至关重要的环节。直接使用数据...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值