此文章主要向大家讲述的是正确实现小数据量与你海量数据之通用分页SQL Server存储过程的显示，在实际操作中建立一个 Web 应用，分页浏览的实际操作功能是必不可少。这个问题是数据库处理中十分常见的问题。
经典的数据分页方法是:ADO 纪录集分页法，也就是利用ADO自带的分页功能（利用游标）来实现分页。但这种分页方法仅适用于较小数据量的情形，因为游标本身有缺点：游标是存放在内存中，很费内存。
游标一建立，就将相关的记录锁住，直到取消游标。游标提供了对特定集合中逐行扫描的手段，一般使用游标来逐行遍历数据，根据取出数据条件的不同进行不同的操作。而对于多表和大表中定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等待甚至死机。
更重要的是，对于非常大的数据模型而言，分页检索时，如果按照传统的每次都加载整个数据源的方法是非常浪费资源的。现在流行的分页方法一般是检索页面大小的块区的数据，而非检索所有的数据，然后单步执行当前行。
最早较好地实现这种根据页面大小和页码来提取数据的方法大概就是“俄罗斯SQL Server存储过程”。这个存储过程用了游标，由于游标的局限性，所以这个方法并没有得到大家的普遍认可。
后来，网上有人改造了此存储过程，下面的存储过程就是结合我们的办公自动化实例写的分页SQL Server存储过程：
CREATE procedure pagination1 (@pagesize int, 页面大小，如每页存储20条记录 @pageindex int 当前页码 ) as set nocount cellSpacing=0 cellPadding=0 width="70%" align=center border=1> 页码 方案1 方案2 方案3 1 60 30 76 10 46 16 63 100 1076 720 130 500 540 12943 83 1000 17110 470 250 10000 24796 4500 140 100000 38326 42283 1553 250000 28140 128720 2330 500000 121686 127846 7168
从上表中，我们可以看出，三种存储过程在执行100页以下的分页命令时，都是可以信任的，速度都很好。但***种方案在执行分页1000页以上后，速度就降了下来。第二种方案大约是在执行分页1万页以上后速度开始降了下来。而第三种方案却始终没有大的降势，后劲仍然很足。
在确定了第三种分页方案后，我们可以据此写一个存储过程。大家知道SQL Server存储过程是事先编译好的SQL语句，它的执行效率要比通过WEB页面传来的SQL语句的执行效率要高。下面的存储过程不仅含有分页方案，还会根据页面传来的参数来确定是否进行数据总数统计。
获取指定页的数据：
- CREATE PROCEDURE pagination3 @tblName varchar(255),
表名 @strGetFields varchar(1000) = ''*'',需要返回的列
@fldName varchar(255)='''', 排序的字段名 @PageSize int = 10, 页尺寸 @PageIndex int = 1, 页码
@doCount bit = 0, 返回记录总数, 非 0 值则返回 @OrderType bit = 0, 设置排序类型, 非 0 值则降序
@strWhere varchar(1500) = '''' 查询条件 (注意: 不要加 where) AS declare @strSQL varchar(5000) 主语句
declare @strTmp varchar(110) 临时变量 declare @strOrder varchar(400) 排序类型
- if @doCount != 0 begin if @strWhere !='''' set @strSQL = "select count(*) as Total from
- " + @tblName + "] where "+@strWhere else set @strSQL = "select count(*) as Total from [" + @tblName + "]" end
以上代码的意思是如果@doCount传递过来的不是0，就执行总数统计。以下的所有代码都是@doCount为0的情况：
- else begin if @OrderType != 0 begin set @strTmp = "<(select min" set @strOrder = " order by [" + @fldName +"] desc"
如果@OrderType不是0，就执行降序，这句很重要！
- end else begin set @strTmp = ">(select max" set @strOrder = " order by [" + @fldName +"]
- asc" end if @PageIndex = 1 begin if @strWhere != '''' set @strSQL = "select top " + str(@PageSize) +" "+
- @strGetFields+ " from [" + @tblName + "] where " + @strWhere + " " + @strOrder else set @strSQL =
- "select top " + str(@PageSize) +" "+@strGetFields+ " from ["+ @tblName + "] "+ @strOrder
如果是***页就执行以上代码，这样会加快执行速度
- end else begin
以下代码赋予了@strSQL以真正执行的SQL代码
- set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+
- " from [" + @tblName + "] where [" + @fldName + "]" + @strTmp + "(["+ @fldName + "])
- from (select top " + str((@PageIndex-1)*@PageSize) + " ["+ @fldName + "] from [" + @tblName +
- "]" + @strOrder + ") as tblTmp)"+ @strOrder if @strWhere != '''' set @strSQL = "select top " + str(@PageSize) +"
- "+@strGetFields+ " from [" + @tblName + "] where [" + @fldName + "]" + @strTmp + "([" + @fldName + "])
- from (select top " + str((@PageIndex-1)*@PageSize) + " [" + @fldName + "] from [" + @tblName + "] where " +
- @strWhere + " " + @strOrder + ") as tblTmp) and " + @strWhere + " " + @strOrder end end exec (@strSQL) GO
上面的这个存储过程是一个通用的SQL Server存储过程，其注释已写在其中了。 在大数据量的情况下，特别是在查询***几页的时候，查询时间一般不会超过9秒；而用其他存储过程，在实践中就会导致超时，所以这个存储过程非常适用于大容量数据库的查询。
笔者希望能够通过对以上SQL Server存储过程的解析，能给大家带来一定的启示，并给工作带来一定的效率提升，同时希望同行提出更优秀的实时数据分页算法。
【编辑推荐】
- SQL Server索引选择的引用与建议
- SQL Server索引的正确使用标准是啥样？
- 三种SQL Server查找数据方法的比较
- SQL Server 索引底层实现的注意事项
- SQL Server 索引的底层实现概述
