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

方便用戶：用戶不可能一次察看所有數據，所以一頁一頁的翻看比較好。
提高性能：一次從數據庫中提取所有數據會比較慢。
那么現在我來嘗試反駁上述理由：

真的方便嗎？我們考慮下面的情況
如果數據只有20條。
如果數據超過1000條。
第一種顯然不必分頁查詢。奇怪的是第二種也不必，因為沒有哪個用戶愿意一頁一頁的翻到最后，如果用戶查詢到的數據超過了他所關心的數據范圍，我認為應該讓他重新輸入查詢條件，就像我們使用google一樣。
但是作為一個友好的應用界面，我們總是希望用戶可以全面的了解他的查詢結果，所以有必要告訴用戶：“你查到了多少數據，但是，目前只能顯示前1000條，如果您希望察看所有數據，那么應該如何如何... ”
性能會提高嗎？
如果數據量很小，顯然性能不會有明顯的提升，相反，性能會大大下降。因為數據庫執行了不必要的查詢和查詢條件。
如果數據量很大，性能也不見得有明顯提升，因為你總是要執行一個額外的count查詢，并且，組合SQL的時候極有可能造成全表掃描。當然這要看數據庫的實現原理了。
可以想像，分頁查詢對于性能的影響和數據量之間的關系應該是一個曲線，數據量小的時候會降低性能，數據量大的時候可能（根據不同的數據庫）會提升性能。關鍵是通過測試，找到曲線的拐點。性能不是根據經驗和感覺得到的，而是通過測試得到的
另外，如果一次全部取出數據，的確會造成空間性能的影響，但是，現在內存很便宜...
負面影響
對于一個架構良好的web應用，將pageNo和PageSize在各個類之間傳遞實在是不爽，這兩個數據明顯屬于表現層。當然，如果你使用RoR算俺沒說。
明顯提高編程復雜度，尤其是在考慮數據庫無關性的時候。
奇怪的現象：為什么沒有一個大型數據庫直接提供分頁查詢？Oracle的RowNo不是用于分頁的，SQLServer的Top更不是。
結論
ExtremeTable、DisplayTag、JSF DataTable都提供了簡單的分頁方式，那就是在結果集合中分頁。使用非常方便，而且使得邏輯清晰，大大提高了工作效率。絕大多數情況下，可以直接使用這種方式。
如果通過測試，發現上述方式影響了性能，那么考慮使用分頁查詢。
對于用戶量很大的應用，因為內存的原因，也可以考慮分頁查詢。但是，我個人更推薦緩存方式：同樣的查詢放在一個緩存中...
采用合理的設計，屏蔽開發人員處理分頁邏輯。比如，將分頁邏輯和count查詢放在父類，開發人員負責組合查詢條件。具體看設計模式吧。
歡迎大家討論！！！