Hibernate怎样把一个Oracle中的表的主键设置成自增,在MyEclipse中又怎样设置自增主键的生成策略

oracle想设置自增长需要用到序列。

用hibernate去做的话。

比如想让id自增长。

第一，建表的时候id设置成主键；

第二，映射的时候选择Id Generator选择sequence；

第三，修改hbmxml文件id的相应位置为：

<id name="ID" type="javalangLong">

<column name="ID" precision="10"

<generator class="sequence">

<param name="sequence">ID</param>

</generator>

</id>

数据千万级别之多，占用的存储空间也比较大，可想而知它不会存储在一块连续的物理空间上，而是链式存储在多个碎片的物理空间上。可能对于长字符串的比较，就用更多的时间查找与比较，这就导致用更多的时间。

可以做表拆分，减少单表字段数量，优化表结构。

在保证主键有效的情况下，检查主键索引的字段顺序，使得查询语句中条件的字段顺序和主键索引的字段顺序保持一致。

主要两种拆分 垂直拆分，水平拆分。

垂直分表

也就是“大表拆小表”，基于列字段进行的。一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。 一般是针对 那种 几百列的大表，也避免查询时，数据量太大造成的“跨页”问题。

垂直分库针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Product一个库，订单Order一个库。 切分后，要放在多个服务器上，而不是一个服务器上。为什么？ 我们想象一下，一个购物网站对外提供服务，会有用户，商品，订单等的CRUD。没拆分之前， 全部都是落到单一的库上的，这会让数据库的单库处理能力成为瓶颈。按垂直分库后，如果还是放在一个数据库服务器上， 随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。 所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。

数据库业务层面的拆分，和服务的“治理”，“降级”机制类似，也能对不同业务的数据分别的进行管理，维护，监控，扩展等。 数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。 数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈。

水平分表

针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈。不建议采用。

水平分库分表

将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

水平分库分表切分规则

1 RANGE

从0到10000一个表，10001到20000一个表；

2 HASH取模

一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。 取用户id，然后hash取模，分配到不同的数据库上。

3 地理区域

比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。

4 时间

按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。

分库分表后面临的问题

事务支持

分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

跨库join

只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

跨节点的count,order by,group by以及聚合函数问题

这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

数据迁移，容量规划，扩容等问题

来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。

ID问题

一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由

一些常见的主键生成策略

UUID

使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。

Twitter的分布式自增ID算法Snowflake

在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位 机器ID 10位 毫秒内序列12位。

跨分片的排序分页

一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。

在hibernate中，通常配置对象关系映射关系有两种，一种是基于xml的方式，另一种是基于annotation的注解方式，熟话说，萝卜青菜，可有所爱，每个人都有自己喜欢的配置方式，我在试了这两种方式以后，发现使用annotation的方式可以更简介，所以这里就简单记录下通过annotation来配置各种映射关系，在hibernate4以后已经将annotation的jar包集成进来了，如果使用hibernate3的版本就需要引入annotation的jar包。

一、单对象 *** 作

@Entity--->如果我们当前这个bean要设置成实体对象，就需要加上Entity这个注解

@Table(name="t_user")---->设置数据库的表名

public class User

{

private int id;

private String username;

private String password;

private Date born;

private Date registerDate;

@Column(name="register_date")--->Column中的name属性对应了数据库的该字段名字，里面还有其他属性，例如length，nullable等等

public Date getRegisterDate()

{

return registerDate;

}

public void setRegisterDate(Date registerDate)

{

thisregisterDate = registerDate;

}

@Id--->定义为数据库的主键ID(建议不要在属性上引入注解，因为属性是private的，如果引入注解会破坏其封装特性，所以建议在getter方法上加入注解)

@GeneratedValue---->ID的生成策略为自动生成

public int getId()

{

return id;

}

public void setId(int id)

{

thisid = id;

}

}

最后只需要在hibernatecfgxml文件里面将该实体类加进去即可：

<!-- 基于annotation的配置 -->

<mapping class="comxiaoluobeanUser"/>

<!-- 基于hbmxml配置文件 -->

<mapping resource="com/xiaoluo/bean/Userhbmxml"/>

这样我们就可以写测试类来进行我们的CRUD *** 作了。

二、一对多的映射(one-to-many)

这里我们定义了两个实体类，一个是ClassRoom，一个是Student，这两者是一对多的关联关系。

ClassRoom类：

@Entity

@Table(name="t_classroom")

public class ClassRoom

{

private int id;

private String className;

private Set<Student> students;

public ClassRoom()

{

students = new HashSet<Student>();

}

public void addStudent(Student student)

{

studentsadd(student);

}

@Id

@GeneratedValue

public int getId()

{

return id;

}

public void setId(int id)

{

thisid = id;

}

public String getClassName()

{

return className;

}

public void setClassName(String className)

{

thisclassName = className;

}

@OneToMany(mappedBy="room")--->OneToMany指定了一对多的关系，mappedBy="room"指定了由多的那一方来维护关联关系，mappedBy指的是多的一方对1的这一方的依赖的属性，(注意：如果没有指定由谁来维护关联关系，则系统会给我们创建一张中间表)

@LazyCollection(LazyCollectionOptionEXTRA)--->LazyCollection属性设置成EXTRA指定了当如果查询数据的个数时候，只会发出一条 count()的语句，提高性能

public Set<Student> getStudents()

{

return students;

}

public void setStudents(Set<Student> students)

{

thisstudents = students;

}

}

Student类：

@Entity

@Table(name="t_student")

public class Student

{

private int id;

private String name;

private int age;

private ClassRoom room;

@ManyToOne(fetch=FetchTypeLAZY)---> ManyToOne指定了多对一的关系，fetch=FetchTypeLAZY属性表示在多的那一方通过延迟加载的方式加载对象(默认不是延迟加载)

@JoinColumn(name="rid")--->通过 JoinColumn 的name属性指定了外键的名称 rid　(注意：如果我们不通过JoinColum来指定外键的名称，系统会给我们声明一个名称)

public ClassRoom getRoom()

{

return room;

}

public void setRoom(ClassRoom room)

{

thisroom = room;

}

@Id

@GeneratedValue

public int getId()

{

return id;

}

public void setId(int id)

{

thisid = id;

}

public String getName()

{

return name;

}

public void setName(String name)

{

thisname = name;

}

public int getAge()

{

return age;

}

public void setAge(int age)

{

thisage = age;

}

附上出处链接：>

你想使用数据库本身的自增长，又想从指定数值开始

Hibernate

主键列设置

<generator class="identity" />

是由数据库自己生成的，但这个主键必须设置为自增长，使用identity的前提条件是底层数据库支持自动增长字段类型，如DB2、SQL Server、MySQL、Sybase和HypersonicSQL等，Oracle这类没有自增字段的则不支持。

这是Hibernate本身无法去控制从什么地方开始（如果你自己写序列，不用数据库的自增长可以）

解决方法：

只有在建表的时候，设置表自增数值：ALTER TABLE tablename AUTO_INCREMENT=1000

您好，increment：代理主键，适合于所有数据库，由hibernate维护主键自增，和底层数据库无关，但是不适合于2个或以上hibernate进程。

identity：代理主键，适合于Mysql或ms sql server等支持自增的dbms，主键值不由hibernate维护。

sequence：代理主键，适合于oracle等支持序列的dbms，主键值不由hibernate维护，由序列产生。

native：代理主键，根据底层数据库的具体特性选择适合的主键生成策略，如果是mysql或sqlserver，选择identity，如果是oracle，选择sequence。

hilo：代理主键，hibernate把特定表的字段作为hign值，生成主键值

uuidhex：代理主键，hibernate采用uuid 128位算法生成基于字符串的主键值

assign：适合于应用程序维护的自然主键。

想要实现安全的自增只能使用hibernate维护得自增属性identity，或者使用开发者自己维护id值assign。如果使用identify，经过测试发现使用无论开发者是否给对象的id赋值，hibernate在保存对象时会自动给id赋值（为mysql表中id最大值+1）；如果使用assign，用户在保存对象前必须给对象的id赋值，值必须大于等于0，如果等于0时，那么数据表id记录会使用mysql数据库维护的最大id+1，如果大于0时，则表id则为用户设置的对象的id值。

经过实验得出，想要实现mysql的sql语句句式以及最终效果，需要设置hibernate配置文件的id自增属性为assign，如果知道id的话则设置对象的id为已知的id，否则设置id的值为0,。

如果id自增属性为assign，那么hibernate保存对象后，对象的id仍然为保存前设置的值；

如果id自增属性为identity，那么hibernate保存对象后，对象的id为数据库中该条记录的id的值。

如果使用assign，必须给对象的id赋值，如果等于0，那么id等于mysql数据库维护的最大id+1，大于0时，id才是你设置特定id值。

所以使用assign同时想使用特定id 就不要使用0来赋值了。

以上就是关于Hibernate怎样把一个Oracle中的表的主键设置成自增,在MyEclipse中又怎样设置自增主键的生成策略全部的内容，包括:Hibernate怎样把一个Oracle中的表的主键设置成自增,在MyEclipse中又怎样设置自增主键的生成策略、Mysql某个表有近千万数据，CRUD比较慢，如何优化、hibernate 注解 根据ID查询没有关联的实体等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！