ACCESS数据库大数据量分页的几种方法.doc

ACCESS数据库大数据量分页的几种方法比较及测试结果分析 本文解决的问题：1.ACCESS是否存在更有效率的分页方法？2.现有ACCESS大数据量10万条数据分页的效率测试3.ACCESS的数据承载量到底有多大？ ??? 相信很多ASP的站点还在使用access数据库，因为access数据库无须开专门的数据库空间，调用，迁移也方便，节省费用。另外对网站搭建者的专业能力要求也相对低一些。但随着网站的运行，数据库体积越来越大，数据量也从最初的几百条到了现在的上万条，上十万条甚至更多。于是因数据应用级别的改变带来的各种各样的应用问题出现了。而其中大数据量的列表分页效率问题更是让很多人头疼。笔者随便通过“大数据量分页效率”，“access 分页”等关键词分别百度和谷歌了一下，发现有此疑问的大有人在。很多网页上也给出了不同的解决办法。那么，这些方法到底能达到优化效率，提高速度的目的吗？??? 先让我们来看看以下的几个access分页优化方案，当然如果你直接将数据库升级到sql server，那么有更好的诸如存储过程等方法。今天我们就讨论一下access大数据量优化分页方法，以及access到底能承受多少数据量。方案一：利用ado本身的结果集的pagesize，AbsolutePage的属性来进行分页程序示例：（仅供示意，完善的各种条件判断自行添加）MaxPerPage=20page=cint(request(page)) sql=select * from 表 where 条件 order by 排序条件set rst=server.CreateObject(adodb.recordset)rst.open sql,conn,1,1rst.pagesize=MaxPerPagerst.AbsolutePage = Page?? 将记录定位到对应页数的第一条for i=1 to MaxPerPage??? 循环列表??? rst.movenext??? if rst.eof then exit fornext 这个方法是最为常用的access分页方法。缺点：每次都要读入符合条件的所有记录，然后再定位于对应页的记录。当数据量大的时候，效率就十分的低下。与此相似的方法是利用ado的move方法，每次将记录集游标移动 (1)*pagesize ，就实现了了记录的分页。经过测试，效率与方案一大致相同。 方案二：1.设置一个自增长字段.并且该字段为INDEX. 2.由于是 ACCESS ,所以,只能是前台分页.自增长字段目的,就是为了实现分页功能. ??? 1 记录用户前页的最后一个 自增值 ,例如 M . 　　2 下一页,取下一页的开始值.M+1 ,结束值: M+1+1.5*PAGESIZE (注:由于数据库会有增删操作,故应该取页大小应该有一个系数,你可以根据情况自定一个1大的系数. 　　3 前台循环取 RS 的前 PAGESIZE 条, 写到一个 新的RS中,并返回. 这个方案通过自增值来分部截取不同分页的数据列表，文中考虑到数据库有增删操作，所以加入了一个系数的概念，这是一个不得已的做法。这个方案可以保证分页效率，但只能运用于增删不太频繁（自增值字段相邻记录的值相差不多的情况）的数据表。 方案三：not in 方法。这个方案在很多网站上都转载。据说对于越往前的分页效率提高越明显。我一直有所怀疑，因为“not in”本身就是个耗费资源的算法。很难相信一个低效率的方法能提高大数据量分页的效率。示例如下：sql=select top 12 * from 表 where Id not in(select top page*pagesize Id from 表 order by id desc) order by Id desc如果是第9页，每页20条即select top 20 * from 表 where Id not in(select top 9*20 Id from 表 order by id desc) order by Id desc 原理即：选择top 20 的记录，条件是id不在前面分页的记录ID里。通过这种方式过滤掉前面分页的记录，然后通过top高效率的方式获取当页的记录。“top”确实高效，但是“not in”呢？于是我直接用这种方法测试了一下，测试条件：10万条数据。点击查询 MY GOD，长时间无响应，最后Ctrl+Alt+Delete 结束任务。再试，结果同样如此。于是改变一下测试条件，变成1000条数据，OK，结果显示非常顺利。结论：如果你是大数据量分页，还是不要用这种方法，会死人的。 方案四：select * from (select top pagesi