建站技術網專注分享網站建設技術,網站建設教程,真正幫你學會做網站技術,輕松解決網站建設過程中遇到的常見問題,為廣大站長服務。 網站地圖 | 收藏本站 | 訂閱
域名投資,就來找米網,認準網址:www.zhaomi.cc 專業仿站,就到仿站網:www.fangzhan.org
  站內公告: ·帝國cms教程內容已更新,歡迎關注     ·建站技術網采用阿里云服務器,備案已通    
您當前的位置:建站技術網 > 數據庫教程 > Access教程

access的分頁查詢效率問題

時間:2018-02-02 15:52:22  來源:網絡收集  整理: 建站技術網 www.txwlqq.com     點擊:17次


本文解決的問題:

1.ACCESS是否存在更有效率的分頁方法?

2.現有ACCESS大數據量10萬條數據分頁的效率測試

3.ACCESS的數據承載量到底有多大?


    相信很多ASP的站點還在使用access數據庫,因為access數據庫無須開專門的數據庫空間,調用,遷移也方便,節省費用。另外對網站搭建者的專業能力要求也相對低一些。但隨著網站的運行,數據庫體積越來越大,數據量也從最初的幾百條到了現在的上萬條,上十萬條甚至更多。于是因數據應用級別的改變帶來的各種各樣的應用問題出現了。而其中大數據量的列表分頁效率問題更是讓很多人頭疼。筆者隨便通過“大數據量分頁效率”,“access 分頁”等關鍵詞分別百度和谷歌了一下,發現有此疑問的大有人在。很多網頁上也給出了不同的解決辦法。那么,這些方法到底能達到優化效率,提高速度的目的嗎?

    先讓我們來看看以下的幾個access分頁優化方案,當然如果你直接將數據庫升級到sql server,那么有更好的諸如存儲過程等方法。今天我們就討論一下access大數據量優化分頁方法,以及access到底能承受多少數據量。

方案一:利用ado本身的結果集的pagesize,AbsolutePage的屬性來進行分頁

程序示例:(僅供示意,完善的各種條件判斷自行添加)

MaxPerPage=20

page=cint(request("page"))


sql="select * from 表 where 條件 order by 排序條件"

set rst=server.CreateObject("adodb.recordset")

rst.open sql,conn,1,1

rst.pagesize=MaxPerPage

rst.AbsolutePage = Page   '將記錄定位到對應頁數的第一條

for i=1 to MaxPerPage

    循環列表

    rst.movenext

    if rst.eof then exit for

next


這個方法是最為常用的access分頁方法。

缺點:每次都要讀入符合條件的所有記錄,然后再定位于對應頁的記錄。當數據量大的時候,效率就十分的低下。

與此相似的方法是利用ado的move方法,每次將記錄集游標移動 (page-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 "&pagesize&" * from (select top "&page*pagesize&" * from 表" order by id desc) order by id) order by id desc"

這個方法簡單說來,就是選取當前頁及小于當前分頁的所有記錄,再通過“Top”方式選取當前頁的記錄。

這個方法沒有出現效率低的語句,雖然至少要select兩次(示例select了三次是為了排序)。但是效率應該不錯。且越靠前的分頁應該越明顯。

如果還想節省效率,可以只select兩次。

假如記錄ID為1-100,每頁5條,F在顯示第4頁,排序為倒序。

執行順序:

1) 選擇前4頁的數據,即100-81共20條數據

2) 從這20條數據中選擇最小的5條,即81-85。

3) 將選擇的5條按倒序排,即成為 85-81。


如果節省第三步也可,只不過顯示變成

第一頁:96,97,98,99,100

第二頁:91,92,93,94,95

.

.

.

其實也不錯。


光說沒用,最終看測試結果。我在相同的數據條件,服務器配置下,分別對方案一中的兩種方法和方案四進行了access分頁效率測試,測試數據如下

測試條件:>10萬條;pagesize=20;分頁總數>5000頁;順便也進行了一下“select 部分字段”和“select 所有字段”的對比測試。


從上面的測試結果來看,方案三的優勢還是比較明顯的。而到5000頁的效率基本上和前兩種方法差不多,甚至仍然有一定得優勢。


另外,很多人在寫select語句時, 習慣 select * from 表,這不是一個好習慣。上面的access分頁測試結果表明,還是按需索要,按需供應的好,需要什么字段,就select什么字段。能夠極大的節省服務器資源。


很多網友提到ACCESS時都不免的輕視,“你還在用access?”,“還不換sql server?”,“用access你還想多快?”。其實在我的經驗看來,即便是在10萬條的應用級別上。access常常比sql server快。因為sql server需要額外連接,且多了一個帶寬連接因素的影響(當然,網站服務器和數據庫服務器運行速度和帶寬都很OK,那沒話說)。

sql server 在更高數據級別上的速度優勢還是比較明顯,畢竟與access不是一個級別的產品。


為了探索一下access數據庫的極限。在40萬條數據的情況下進行了上述分頁測試。速度確實大打折扣。但是第三種方案在一萬頁內還是表現不錯的。此時數據庫已經達到400多兆。再結合之前處理過的幾個4,500兆的access數據庫。我認為40萬條數據是access數據庫在一般應用的一個界限,但不是極限。超過這個數,就需要在程序優化上做太多的工作。就有些不太值了。


標簽:
文章標題:access的分頁查詢效率問題
文章網址:http://www.txwlqq.com/shujuku/Access/3810.html
上一篇:ACCESS數據庫分頁的SQL語句
下一篇:SQL語法 Access
來頂一下
返回首頁
返回首頁
相關文章
    無相關信息
推薦資訊
如何通過SEO優化排名賺錢?SEO賺錢方法
如何通過SEO優化排名賺
seo優化教程:網站seo內容優化
seo優化教程:網站seo
SEO細節:企業SEO如何快速為新站做出效果
SEO細節:企業SEO如何
電商技術將如何發展?2018年有這五個大膽預測
電商技術將如何發展?
最新文章
欄目更新
欄目熱門
成人黄色