数据库分页查询一般分为两步，
(1)根据查询条件，count 记录总数
(2)根据当前页的数据范围(起始位置offset, 每页数据个数span)，从符合查询条件的记录集 取出对应范围的数据。
一、根据范围取数据的方法
如果单纯用JDBC从ResultSet中取出一个指定范围（offset, span）的数据，可以采用这样的方法。
ps = con.prepareStatement(sql, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)；
ps.setMaxRows(offset + span)；
rs = ps.executeQuery();
rs.absolute(offset);
while(rs.next())...
数据量大的时候，页数很多，offset很大，这种方法不太适合。这时候，需要使用各数据库的native SQL特性。
我们来看Hibernate dialect package的类，支持了各种数据库的getLimitString方法。这里举Mysql和Oracle的例子。假设查询语句为
Select * from message where forum_id = ? and created_time > ? order by created_time desc
Mysql 的limit SQL为
Select * from message where forum_id = ? and created_time > ? order by created_time desc
limit ?, ?
后面的两个limit ?, ? 分别为 offset, span。
Oracle的limit SQL为
select * from ( select row_.*, rownum rownum_ from (
Select * from message where forum_id = ? and created_time > ? order by created_time desc
) row_ where rownum <= ?) where rownum_ > ?
后面的两个limit ?, ? 分别为 offset + span, offset。
二、缓存 & QueryKey
count语句可以根据查询语句自动生成，比如
Select count(*) from (
Select * from message where forum_id = ? and created_time > ? order by created_time desc
)
这样的自动count语句有些浪费，用了子查询不说，还保留了没有必要的order by。最好还是另外提供一个count语句。
Select count(*) from message where forum_id = ? and created_time > ?
在多页翻动的情况下，这个count语句要被反复执行。为了提高效率，我把这个count结果保存在全局缓存中，不仅本Session用户可以重复使用，其他用户在根据同样条件翻找message的时候，也可以重复使用这个结果。
我在持久层中使用通用的QueryKey做为缓存键值。
QueryKey分成三个部分，SQL, Parameters, Range。比如：
Query Key:
SQL : Select count(*) from message where forum_id = ? and created_time > ?
Parameters : [buaawhl, time long value]
Range: (0, 1)
这个QueryKey的效率很关键。主要是hashCode和equals两个方法的效率。
我们知道，当key放在Map等Hash数据结构中，首先hashCode，然后用equals比较hashCode后面的一串key。
举个例子。Key1和key2 的hashCode一样，都和key3的hashCode不一样。
…
[ 101 ] -> key1 -> key2
…
[ 666 ] -> key3
…
可以看到，hashCode，equals，这两个方法都是每次查找缓存都要调用的方法。尤其是equals方法更是重中之重，很可能需要被调用多次。
hashCode的优化实现相对来说比较简单，只要根据QueryKey中各部分的不同，尽量实现hashCode取值的扩散化，降低hashCode的重复率就可以了。
关键是equals的实现方案。这里有个原则，越小的结构越先比较，可以提高比较速度。
QueryKey中的parameters和range比较好办。每次equals比较的时候，先比较range，如果不相等，返回false;
如果相等，再比较Parameters，如果有一个parameter value不相等，返回false。这样，我们可以用很短的时间开销
过滤掉一大批不相等的QueryKey。
但是parameters和range都相等的时候，我们还是无可避免的要比较SQL。String的equals方法如下：
// from jdk src
//这个方法没有比较hashCode，直接比较长度和字符
public boolean equals(Object anObject) {
if (this == anObject) {
return true;
}
if (anObject instanceof String) {
String anotherString = (String)anObject;
int n = count;
if (n == anotherString.count) {
char v1[] = value;
char v2[] = anotherString.value;
int i = offset;
int j = anotherString.offset;
while (n-- != 0) {
if (v1[i++] != v2[j++])
return false;
}
return true;
}
}
return false;
}
我们看到，当SQL String很长的时候，长度相等，前面大部分字符相同的时候，(最极端的情况下，两个不同reference的String的字符完全相等)，这个比较是相当消耗时间的。比如，
Select * from message where forum_id = ? and created_time > ? order by created_time desc
和
Select * from message where forum_id = ? and created_time > ? order by updated_time desc
两个String的长度相等，前面大部分也相等，只有走到cre 和 upd 的时候，才能比较出不相同。如果两个字符串内容一样，那更是要走到头，才能判断出两个字符串完全一样了。
我的第一个做法就是，尽量使用static final String做为QueryKey的SQL。这样两个SQL的reference如果相等，那么可以迅速判断出两个SQL相同。
这个做法只能处理事先定义好的SQL语句，但实际需求中，存在很多需要动态拼接SQL的情况，不可能做到所有相同的SQL具有相同的reference。
当然大部分不同的SQL都具有不同的长度，即使长度相同，前面走不了几个字符，就可以判断出不相同。所以做法一已经能够解决95%以上的SQL效率问题。
不过，为了解决这剩下的5%情况，我又采取了第二个做法：分而治之，把一个SQL String拆分成多个SQL常量的数组;泛化SQL的类型，SQL不限制为String类型，也可以是String[]类型。
比如。
String[] sql1 = {
“Select * from message where forum_id = ?”，
“ and created_time > ?”,
“ order by ”,
“created_time”,
“desc”
};
和
String[] sql2 = {
“Select * from message where forum_id = ?”，
“ and created_time > ?”,
“ order by ”,
“created_time”,
“desc”
};
和
String[] sql3 = {
“Select * from message where forum_id = ?”，
“ and created_time > ?”,
“ order by ”,
“updated_time”,
“desc”
};
这个时候，比较sql1和sql2和sql3的效率就会大大提高，虽然sql1 和
sql2两个数组的长度相等，还是要一个元素一个元素的比较，但由于里面大量用到了String常量，相同的String常量具有相同的
reference，所以5步下来，就可以判断出sql1和sql2数组的元素是完全相等的；4步下来，加上第一个字符的比较，就可以判断sql1和
sql3的第4个元素是不相等的。
我们看到，做法1和做法2，能够100%的提高SQL的比较效率，大部分情况下，也许比parameters的比较还快。