原创:SQL Server的通用分页存储过程,未使用游标,速度更快!

使用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下使用的例子:

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值