Access分页问题

    近期打算重新写一下Noter，就先拿数据连接层来热热身，想到以后要有效展示，还是要考虑到查询结果的分页问题。

    在Sql Server等支持存储过程的数据库里，分页也许会简单一点，如果是Access，虽然也是“支持”存储过程，想必要用它的“存储过程”来实现分页，会更麻烦。

    在网上搜了一下，找到了一个博客转的一篇文章，里面介绍了四种方案，就我个人而言，已直接忽略了方案一与方案二，感觉它们有点麻烦，方案三与方案四才是我考虑的重点。

    其实我是想直接不劳而获，从两者中选一种为我所用。但文章后面的分析中，对几种方案作了分析对比，但执行时间上没看到方案四的数据，方案四也只是介绍完就没有对比了，莫非要我选用方案三？可是作者也说了“not in”是效率很低的啊~~~

    所以只有自己动手简单测一下了。

数据：150M的Access文件，表中数据记录25000多条，假设一页只显示100条，取三个字段……我选第10页的100条：

方案三语句：

select top 100 ID, 书名, 版次 from Content where ID not in (select top 900 ID from Content order by ID) order by ID

    结果直接给我“没有响应”……程序死了……变换若干次所取的分页，依旧“没有效应”，可能是由于记录总数太大的原因？还是我数据访问类没写好？没深究，直接忽略，因为我更关注方案四的表现。

方案四语句：

select * from (select top 100 * from (select top 1000 ID,书名,版次 from Content order by ID) order by ID desc) order by ID

    0.156秒！开个好头，尝试更大一点的，比如pagesize是1000，然后取第10页~

select * from (select top 1000 * from (select top 10000 ID,书名,版次 from Content order by ID) order by ID desc) order by ID

    0.375秒！

    如果再加大pagesize到5000，速度就明显地慢了一点，不过也是可以接受的范围，至少没有死去~10.703秒了结。

    发现方案四的速度是与pagesize相关的，一次显示的越多，运行的时间就越长，也有可能是循环赋值导致，总体来讲，要达到目前Noter的应用水平，方案四是足够了。

    另外，方案四其实有个小问题要考虑，就是当pagesize*page > 记录总数，就会导致分页结果不准确，会产生偏移。比如说，表中原有8条记录，pagesize是5，我要是想查第2页……

    按正常的思维，显示的结果应该是第2页只显示记录6~8，只有三条记录，但方案四的算法会导致第二页显示记录4~8，一共五条记录。这是由于算法里翻来覆去排序导致的，不过所幸的是一般只是会影响到那种特殊情况的分页结果，而且无伤大雅。或者可以加个记录总数来控制一下，不过那是后期具体做的时候再考虑的问题了，现在就探索到这吧。