我忘记我是不是写过了，如果写过就跳过吧。为什么写这个，以前出过几次问题，我发现分页写的有问题。很多人不是太明白。我这里列举一下：
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互联网时代是输入框为入库比如百度，谷歌。他们没有总页数，但是就是可以往下找。
在移动互联网时代，就是手指滑动了，也没有总页数。比如微博、朋友圈，也是没有总页数，往下滑。
只有数据量较小的场景（比如邮箱）才需要总页数。那么可以结合自己情况选择要不要总页数。强烈推荐不要总页数，就一页一页往下走，这才符合互联网场景，除非你不是面向互联网应用的。
