使用SQL Server时,分页处理一直是个比较棘手的问题
执行一个数据检索的请求,涉及到三个环节:
1、请求者的本地浏览器,简称为:C
2、接收HTTP请求的WEB服务器,简称为:SW
3、接收数据请求的SQL Server服务器,简称为:SD
正常情况下,SQL Server服务器上会对使用频率大的Table建立合适的索引
这样能大幅度的提高SD本身的数据检索速度,建立索引的方法就不细说了
如果需要返回大量数据,从几百行到几万行,甚至几十万行数据
这时会发现响应速度越来越慢,甚至发生响应超时的错误
为了解决这种大数据量请求的问题,出现了分页机制
分页机制有两种:
1、SD执行数据检索,然后将检索结果直接发送给SW,由SW进行分页,然后将指定页的数据发送给C
这种分页机制在以SQL Server为数据库的应用中是很常见的
优点是使用简单,主要是利用ADO的PageSize和AbsolutePage两个属性,SW仅向C返回指定页数的数据,数据量减少了,响应速度有所提高
缺点很明显,每次请求时,都要从SD返回全部符合的数据,从数据传输、SW的处理时间上都还存在很大的浪费,虽然SW向C的返回数据进行了分页处理,但SD到SW的数据还未进行分页
2、SD执行数据检索,并对检索结果进行分页,然后将指定页的数据发送给SW,SW将接收到的数据直接发送给C
可以看到,这种方式从SD开始就进行了分页处理,将不是当前页的数据直接过滤掉,仅将剩下的数据发送给SW
这样在数据传输上,在SW的数据处理速度上都会有大幅度的提高
这种方式无法使用ADO处理,因为ADO没有办法告诉SQL Server仅返回指定行的数据,只能都返回之后再处理
在这点上,JDBC就强悍得多,它可以将指定的行数和SQL请求一并发送给SQL Server,这样只返回分页后的数据,JDBC的原理还不清楚,但在实际使用中,速度还是非常快的,使用JDBC的分页方法很简单,不在本文的讨论范围之内
如果没办法使用JDBC,最常用的方法就是存储过程了!
我在写这个分页存储之前,参考了网上的大量相关文章,可以通过关键字:SQL Server 分页 进行搜索
他们主要都是利用SQL中的Top方法,并且对所检索的数据结构要求有标识列,如果没有标识列,或者是联合主键,那么就会非常麻烦了。而且对应用里原有的SQL检索部分需要修改的地方较多,工作量较大。
因此,我在写这个存储之前就要求一定要对原有的SQL脚本最大程度的兼容
经过一个下午的时间,和我一个同事(绝对是高手)的共同努力下,摸索出了以下的思路:
1、确定存储的输入参数:
1)SQL脚本,该参数接收完整的、正确的SQL检索文本,可将原应用中写好的SQL脚本直接传入
2)每页的数据容量,就是一页有多少条数据
3)当前页码
2、确定分页机制:
1)执行传入的SQL脚本,并将结果生成临时表
2)修改临时表的结构,增加标识列字段
3)根据标识列字段,计算出指定页码内的记录范围,并返回
4)返回总数据条数,用于客户端进行分页显示
根据以上的思路,编写出以下通用的分页存储过程:
举个在ASP下使用的例子: