用in还是exists
用exists,原因是效率比in高
使用本地sql
SQLQuery q = session.createSQLQuery("select * from category limit 2,4").addEntity(Category.class);---转换成Category对象
List<Category> categories = (List<Category>)q.list();
HQL语言详细使用的时候查一下hibernate_2400和2500
q.executeUpdate();
q.list();
q.uniqueResult() 返回的是唯一的结果
有经验的项目经理要求只用某一种查询方式
1.native sql 》HQL 》EJBQL 》QBC(QUERY by Criteria) >QBE(Query By Example)
Criteria->Criterion
Criteria c = session.createCriteria(Topic.class) //from Topic 为这个类创建一系列的约束
.add(Restrictions.gt("id", 2)) //greater than = id > 2
.add(Restrictions.lt("id", 8)) //little than = id < 8
.add(Restrictions.like("title", "t_"))
.createCriteria("category")
.add(Restrictions.between("id", 3, 5)) //category.id >= 3 and category.id <=5;
for(Object o : c.list()) {
Topic t = (Topic)o;
System.out.println(t.getId() + "-" + t.getTitle());
}
性能优化
1.注意session.clear()的运用,尤其在不断分页循环的时候
a)在一个大集合中进行遍历,遍历msg,取出其中含有敏感字样的对象
b)另外一种形式的内存泄露
在同一个session中不断处理对象,需要手动清除session的缓存对象,应该每处理完50条调用session.clear()
java有内存泄露吗?语法级别没有,但是对于资源的使用有可能造成该问题,像打开文件。上面这个session场景可能就会造成内存泄露
2.1+N问题 ----典型的面试题
a)lazy
b)BatchSize
c)join fetch
session.createCriteria默认就解决了1+N的问题
一对多或者多对一经常会出现,只要fetch=FetchType.EAGER,本来一条sql能解决问题,结果用了1+N条sql才解决
三种解决方案:
<1>fetch设置为lazy ----N条sql语句用到的时候发出,不用的时候不发出
<2>BatchSize的使用位置,一定程度上帮你提高效率,对于解决这个问题不太正规----这种方法该取的还是要取,只是每次取设定的条数来减少取的次数
如N=10的时候BatchSize为5的话,会分为2次取,每次取5条
<3>from Topic t left join fetch t.category c ---这个类似于使用session.createCriteria
2012-3-19
3.list和iterator不同之处----不太重要,一般用list就可以,两个都不允许用join
Iterator在hasNext()为false的时候不允许调用next()否则报错
a)list取所有----同一个session中执行2遍就会发2次sql语句
b)iterator先取id,等用到的时候再根据id取对象(用的不多,会利用session级缓存,对程序精益求精)
c)session中list第二次发出,仍会到数据库查询
d)iterator第二次,找到id,然后首先找session级缓存
4.一级缓存、二级缓存和查询缓存
查询缓存,只有在两个查询语句一样的情况下,才能起作用。
a)什么是缓存
b)什么是一级缓存,session级的缓存
c)什么是二级缓存,sessionFactory级别的缓存,可以跨越session存在
(1)经常访问的
(2)改动不大,不会经常改动
(3)数量有限
d)打开二级缓存
i.hibernate.cfg.xml设定:
<property name="cache.use_second_level_cache">true</property>
<property name="cache.provider_class">org.hibernate.cache.EhcacheProvider</property>
ehcache需要有自己的配置文件
改动频繁不适合放缓存.(1)经常访问的(2)改动不大(3)数量有限
比如:用户的权限
二级缓存中有一种特殊的缓存,查询缓存,重复查询才能使用的缓存
ii.@Cache注解
e)load默认使用二级缓存,iterator默认使用二级缓存
f)list默认往二级缓存加数据,需要打开查询缓存,查询的时候不用
g)如果要query用二级缓存,需要打开查询缓存
i.<property name="cache.use_query_cache">true</property>--------查询缓存是依赖于二级缓存的,要先打开二级缓存再打开查询缓存
ii.调用Query的setCachable(true)方法指明使用二级缓存--------list()方法可以使用查询缓存
h)缓存算法:(纯为了面试)----内存中对象满了以后,新来对象后怎么处理原来的对象,哪个对象被拿走
i.LRU,LFU,FIFO
<1>Least Recently Used 最近很少使用
<2>Least Frequently Used (命中率高低)
<3>First In First Out 先进先出
ii.memoryStoreEvictionPolicy="LRU"(ecache)
5.事务并发处理
a)事务:ACID
<1>Atomic 原子性
<2>Consistency 一致性
<3>Itegrity 独立性
<4>Durability 持久性
b)事务并发时可能出现的问题
脏读:读到了别的事物还没有提交的数据
不可重复读:在两次读数据间,数据被其他事务改变了
幻读:插入和删除的操作,读的过程中,另外一个事物插入了一个新记录
c)数据库事物隔离机制
<1>查看java.sql.Connection
<2>1.read-uncommitted 2.read-committed 4.repeatable-read 8.serializable
a) 0001 0010 0100 1000
b) C R U D
c)C|U 0101
d)0101 & 0001 == 0001
java注重的是开发效率,而不是程序效率
oracle支持2种 mysql支持4种
mysql:select @@tx_isolation;
read-uncommitted:能够读那些没有提交的数据,会产生dirty-read,phantom-read,non-repeatable read问题
read-committed:提交了之后才能读出来,不会出现dirty-read,会出现non-repeatable read,phantom-read
repeatable-read:可重复读,读出来之后加一把锁,该事物用完了才能被其他事物更新
serial:解决一切问题
----------效率从上到下变低,安全从下到上变高
解决phantom read只能serial
d)设定hibernate的事务隔离级别
<1> hibernate.connection.isolation=2-----如果不设置,那么依赖于数据库read-committed
<2> 用悲观锁解决repeatable read的问题(依赖于数据库的锁)
1.select ... for update;
2.load(xx.class, i, LockMode.UPGRADE)
load()第三个参数用LockMode.UPGRADE,几个锁中只能使用这个锁
悲观,先上把锁,不让别人更新,使用数据库的锁
乐观,做一个标记,然后运行,改变值前检查标记是否变化,如果没有变化,就正常更新。如果有变化,就重新读数据,重新计算。
加一个@Version的字段