发疯Hibernate分页问题,性能优化!

查询结果写到session里用display tag

可以参考论坛的实现方法，做一个cache保存总数。添加就+1,删除就-1.
时不时的修正一下数据就可以了。

查询多半是带条件的，结果往往不是缓存的总数。

论坛的这种缓存策略只适合特定需求的。

我现在用的是displaytag经过优化了。。其实也不错 而且代码量很少

select count(*) 还能再优化吗?，还是把最常用的分页，第一页count(*)后结果和列表结果，缓存的好。第一页是最常用的了。

Criteria criteria = session.createCriteria(Blog.class);
return criteria.setProjection(Projections.rowCount()).uniqueResult();

这个就是select count(*)

4300万的数据 用户不可能查出这么多的数据，1页1页的翻着看吧。
我要是用户我准是疯了。

可能给用户分页100页，每页100条(那就是100×100＝10000条)，就已经疯了。当然，有时候他想知道总数，那就给他提供一个可查看总数的地方。不过我认为，分页这里没有几个用户分了100页，1页1页看的。

所以可以考虑在查询条件方面限制用户查出那么多的数据，比如用户必须选择某个查询条件等。
而且，只在第1次访问的时候计算总数，其他翻页的时候把总数和分页数等传过去好了。

放一个List getPage(int page)的方法出来，如果返回的list是empty的， 给用户弹个对话框就说找不着了。至于跳转....提供首尾页和上下翻的按钮， 再提供一个页码输入框......大不了我不告诉你到底有多少记录.....
一定要计算Count的话，尽量避免count(*)的出现。


不过我实际环境中还没用过这种方法. 只是一个想法。

计算Count数据库可能有点小负担，而且还是count(*)。

按不同条件进行查询的话，好象就不好用了
我是使用SELECT COUNT 来返回总数