oracle数据库,主键设置为ID,插入语句时,如何自动生成ID并让它顺序增加呢

oracle数据库,主键设置为ID,插入语句时,如何自动生成ID并让它顺序增加呢,第1张

使用oracle数据库中的关键字sequence来实现目的。

//创建mySeq

create sequence mySeq

start with 1

increment by 2

maxvalue 40

minvalue 1

cycle

//创建用户表

create table USER

(

Id int,

CompName varchar2(20)

)

插入语句可以这样写:

insert into USER values(mySeq.nextVal,'AA')

这样的话每次插入的ID就是自动递增的

扩展资料:

sequence用法:

create sequence <序列名称>

start with <起始数>

increment by <增长量>

[maxvalue 值]

[minvalue 值]

[cycle 当到达最大值的时候,将继续从头开始]

[Nocycle -- 一直累加,不循环]

[Cache ]

参考资料:百度百科-oraclesequence

数据库表ID设置实现能自动增长的步骤如下(以TB_News表为例):

步骤1:首先检查你的新闻表ID列的数据类型,要设置为自增列,需要该列的数据类型为int或者bigint等数值类型

步骤2:打开sqlserver management studio,右键点击你的新闻表,选择“设计”

步骤3:在第1步打开的表结构设置界面,点击你的列“ID”,在底下的列属性设置界面做如下设置:

进行完以上步骤,即可在该数据表中插入数据时,不用给ID列赋值,ID列的值会自动生成,并且该列的值会自动增长。

在简单系统中,我们常常使用db的id自增方式来标识和保存数据,随着系统的复杂,数据的增多,分库分表成为了常见的方案,db自增已无法满足要求。这时候全局唯一的id生成系统就派上了用场。当然这只是id生成其中的一种应用场景。那么id生成系统有哪些要求呢?

我们先来看一下最常见的id生成方式,db的auto_increment,相信大家都非常熟悉,我也见过一些同学在实战中使用这种方案来获取一个id,这个方案的优点是简单,缺点是每次只能向db获取一个id,性能比较差,对db访问比较频繁,db的压力会比较大。那么是不是可以对这种方案优化一下呢,可否一次向db获取一批id呢?答案当然是可以的。

 一批id,我们可以看成是一个id范围,例如(1000,2000],这个1000到2000也可以称为一个"号段",我们一次向db申请一个号段,加载到内存中,然后采用自增的方式来生成id,这个号段用完后,再次向db申请一个新的号段,这样对db的压力就减轻了很多,同时内存中直接生成id,性能则提高了很多。那么保存db号段的表该怎设计呢?

如上表,我们很容易想到的是db直接存储一个范围(start_id,end_id],当这批id使用完毕后,我们做一次update *** 作,update start_id=2000(end_id), end_id=3000(end_id+1000),update成功了,则说明获取到了下一个id范围。仔细想想,实际上start_id并没有起什么作用,新的号段总是(end_id,end_id+1000]。所以这里我们更改一下,db设计应该是这样的

那么我们可以通过如下几个步骤来获取一个可用的号段,

如上我们已经完成了号段生成逻辑,那么我们的id生成服务架构可能是这样的

id生成系统向外提供http服务,请求经过我们的负载均衡router,到达其中一台tinyid-server,从事先加载好的号段中获取一个id,如果号段还没有加载,或者已经用完,则向db再申请一个新的可用号段,多台server之间因为号段生成算法的原子性,而保证每台server上的可用号段不重,从而使id生成不重。

 可以看到如果tinyid-server如果重启了,那么号段就作废了,会浪费一部分id;同时id也不会连续;每次请求可能会打到不同的机器上,id也不是单调递增的,而是趋势递增的,不过这对于大部分业务都是可接受的。

到此一个简单的id生成系统就完成了,那么是否还存在问题呢?回想一下我们最开始的id生成系统要求,高性能、高可用、简单易用,在上面这套架构里,至少还存在以下问题:

对于号段用完需要访问db,我们很容易想到在号段用到一定程度的时候,就去异步加载下一个号段,保证内存中始终有可用号段,则可避免性能波动。

db只有一个master时,如果db不可用(down掉或者主从延迟比较大),则获取号段不可用。实际上我们可以支持多个db,比如2个db,A和B,我们获取号段可以随机从其中一台上获取。那么如果A,B都获取到了同一号段,我们怎么保证生成的id不重呢?tinyid是这么做的,让A只生成偶数id,B只生产奇数id,对应的db设计增加了两个字段,如下所示

delta代表id每次的增量,remainder代表余数,例如可以将A,B都delta都设置2,remainder分别设置为0,1则,A的号段只生成偶数号段,B是奇数号段。 通过delta和remainder两个字段我们可以根据使用方的需求灵活设计db个数,同时也可以为使用方提供只生产类似奇数的id序列。

使用http获取一个id,存在网络开销,是否可以本地生成id?为此我们提供了tinyid-client,我们可以向tinyid-server发送请求来获取可用号段,之后在本地构建双号段、id生成,如此id生成则变成纯本地 *** 作,性能大大提升,因为本地有双号段缓存,则可以容忍tinyid-server一段时间的down掉,可用性也有了比较大的提升。

最终我们的架构可能是这样的


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/9992935.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-04
下一篇2023-05-04

发表评论

登录后才能评论

评论列表(0条)

    保存