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