應該怎麼分頁？

我忘記我是不是寫過了，如果寫過就跳過吧。為什麼寫這個，以前出過幾次問題，我發現分頁寫的有問題。很多人不是太明白。我這裡列舉一下：

   A場景： select * from t where rownum<10 或者 limit 10  或者用fetch first 10 rows only;

這種場景：不管表中資料量是TB級別還是PB級別，查詢KB返回KB。

   B場景： select count（*） from t 

這種場景：不管資料量是TB級別還是PB級別，查詢TB或者PB，返回KB。

    然後說明一下A場景 Select count（*）from t;基本記憶體查詢可能涉及少量磁碟查詢，返回byte或者KB。他的 效率不等於 B場景  select * from t; 基本是磁碟查詢，返回MB甚至GB。這是成千上萬倍的差異。

  C場景 Select count（*）from t;    效率不等於 select count(1) from (select * from t;) 等於2個B場景（一個應用SQL一個框架SQL）

  D場景 Select count（*）from t;    效率更加不等於 select count(1) from (select * from t   複雜查詢加排序;) 等於2個B場景（一個應用SQL一個框架SQL）

 而我們在日常工作中C和D是日常最大的問題也是最常見的。都是甩鍋給框架，框架說沒人逼著你用啊？

    那遇到CD兩種場景怎麼做？

1、SQL寫的好點，確保SQL在毫秒級別完成；（單機上億也做得到，做不到的先最佳化設計和SQL）

2、SQL不好改的話，就簡單分頁不要總頁數。就直接limit的一次次去往下找。

在PC網際網路時代是輸入框為入庫比如百度，谷歌。他們沒有總頁數，但是就是可以往下找。

在移動網際網路時代，就是手指滑動了，也沒有總頁數。比如微博、朋友圈，也是沒有總頁數，往下滑。

只有資料量較小的場景（比如郵箱）才需要總頁數。那麼可以結合自己情況選擇要不要總頁數。強烈推薦不要總頁數，就一頁一頁往下走，這才符合網際網路場景，除非你不是面向網際網路應用的。