關於分頁查詢和效能問題

來源:互聯網
上載者:User

  分頁查詢是經常能夠遇到的問題,我們首先看看分頁查詢存在的理由:

  方便使用者:使用者不可能一次察看所有資料,所以一頁一頁的翻看比較好。

  提高效能:一次從資料庫中提取所有資料會比較慢。

  那麼現在我來嘗試反駁上述理由:

  真的方便嗎?我們考慮下面的情況

  如果資料只有20條。

  如果資料超過1000條。

  第一種顯然不必分頁查詢。奇怪的是第二種也不必,因為沒有哪個使用者願意一頁一頁的翻到最後,如果使用者查詢到的資料超過了他所關心的資料範圍,我認為應該讓他重新輸入查詢條件,就像我們使用google一樣。

  但是作為一個友好的應用介面,我們總是希望使用者可以全面的瞭解他的查詢結果,所以有必要告訴使用者:“你查到了多少資料,但是,目前只能顯示前1000條,如果您希望察看所有資料,那麼應該如何如何... ”

  效能會提高嗎?

  如果資料量很小,顯然效能不會有明顯的提升,相反,效能會大大下降。因為資料庫執行了不必要的查詢和查詢條件。

  如果資料量很大,效能也不見得有明顯提升,因為你總是要執行一個額外的count查詢,並且,組合SQL的時候極有可能造成全表掃描。當然這要看資料庫的實現原理了。

  可以想像,分頁查詢對於效能的影響和資料量之間的關係應該是一個曲線,資料量小的時候會降低效能,資料量大的時候可能(根據不同的資料庫)會提升效能。關鍵是通過測試,找到曲線的拐點。效能不是根據經驗和感覺得到的,而是通過測試得到的

  另外,如果一次全部取出資料,的確會造成空間效能的影響,但是,現在記憶體很便宜...

負面影響

  對於一個架構良好的web應用,將pageNo和PageSize在各個類之間傳遞實在是不爽,這兩個資料明顯屬於表現層。當然,如果你使用RoR算俺沒說。

  明顯提高編程複雜度,尤其是在考慮資料庫無關性的時候。

  奇怪的現象:為什麼沒有一個大型資料庫直接提供分頁查詢?Oracle的RowNo不是用於分頁的,SQLServer的Top更不是。

結論

  ExtremeTable、DisplayTag、JSF DataTable都提供了簡單的分頁方式,那就是在結果集合中分頁。使用非常方便,而且使得邏輯清晰,大大提高了工作效率。絕大多數情況下,可以直接使用這種方式。

  如果通過測試,發現上述方式影響了效能,那麼考慮使用分頁查詢。

  對於使用者量很大的應用,因為記憶體的原因,也可以考慮分頁查詢。但是,我個人更推薦緩衝方式:同樣的查詢放在一個緩衝中...

  採用合理的設計,屏蔽開發人員處理分頁邏輯。比如,將分頁邏輯和count查詢放在父類,開發人員負責組合查詢條件。具體看設計模式吧。

  請作者聯絡本站,及時附註您的姓名。聯絡郵箱:edu#chinaz.com(把#改為@)。



相關文章

Alibaba Cloud 10 Year Anniversary

With You, We are Shaping a Digital World, 2009-2019

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。