分页查询

Oracle分页

Oracle分页查询语句基本上可以按照本文给出的格式来进行套用。
Oracle分分页查询格式：

SELECT * FROM  
(  
SELECT A.*, ROWNUM RN  
FROM (SELECT * FROM TABLE_NAME) A  
WHERE ROWNUM <= 40  
)  
WHERE RN >= 21

其中最内层的查询SELECT * FROM TABLE_NAME表示不进行翻页的原始查询语句。ROWNUM <= 40和RN >= 21控制分页查询的每页的范围。

上面给出的这个Oracle分分页查询语句，在大多数情况拥有较高的效率。分页的目的就是控制输出结果集大小，将结果尽快的返回。在上面的分页查询语句中，这种考虑主要体现在WHERE ROWNUM <= 40这句上。

选择第21到40条记录存在两种方法，一种是上面例子中展示的在查询的第二层通过ROWNUM <= 40来控制最大值，在查询的最外层控制最小值。而另一种方式是去掉查询第二层的WHERE ROWNUM <= 40语句，在查询的最外层控制分页的最小值和最大值。查询语句如下：

SELECT * FROM  
(  
SELECT A.*, ROWNUM RN  
FROM (SELECT * FROM TABLE_NAME) A  
)  
WHERE RN BETWEEN 21 AND 40

对比这两种写法，绝大多数的情况下，第一个查询的效率比第二个高得多。

这是由于CBO 优化模式下，Oracle可以将外层的查询条件推到内层查询中，以提高内层查询的执行效率。对于第一个查询语句，第二层的查询条件WHERE ROWNUM <= 40就可以被Oracle推入到内层查询中，这样Oracle查询的结果一旦超过了ROWNUM限制条件，就终止查询将结果返回了。

而第二个查询语句，由于查询条件BETWEEN 21 AND 40是存在于查询的第三层，而Oracle无法将第三层的查询条件推到最内层（即使推到最内层也没有意义，因为最内层查询不知道RN代表什么）。因此，对于第二个查询语句，Oracle最内层返回给中间层的是所有满足条件的数据，而中间层返回给最外层的也是所有数据。数据的过滤在最外层完成，显然这个效率要比第一个查询低得多。

上面分析的查询不仅仅是针对单表的简单查询，对于最内层查询是复杂的多表联合查询或最内层查询包含排序的情况一样有效。

//page是页数，rows是显示行数
        int page=2;
        int rows=5;                            
        List<Articles> list=a.select(page*rows+1，(page-1)*rows);
        //  sql语句：  select * from(select a.*,rownum rn from (select * from t_articles) a where rownum < 11) where rn>5
　　　　　　//第一个参数，对应着第一个rownum<11,第二个参数对应着rn>5

---

一、rownum是一种伪列，它会根据返回数据自动生成一个数字，但是这个伪列的特殊性，我们在使用的时候需要注意以下几点:

1、伪列要显示必须写出来，也就是放在select中；
2、rownum永远从1开始、行号只能使用<,<= 不能使用>,>=；（这点解释了为什么不直接写成WHERE ROWNUM <= 40 AND ROWNUM >= 21,而要分开写的原因）

oracle数据库是行式数据库，只有取了第一行才能取第二行，取了第二行才能取第三行…..oracle中rownum永远从1开始的，所以rownum不能使用>、>=(比如：盖8层楼，1234层都没有盖，怎么能盖5678?)
3、rownum按照默认的顺序生成，不会因为排序而发生变化；
比如、要查询员工薪水前三名

<code class="language-sql"><span style="font-size:18px;">select rownum,empno,ename,sal  
     from emp order by sal desc   
        where rownum<=3；</span></code>  

以上执行结果是错的，只是取原来员工表前三个。以为以下sql执行结果如图所示（未排序结果）

select rownum,empno,ename,sal
     from emp；

接下来我们将该表进行排序：

select rownum,empno,ename,sal
     from emp order by sal desc；

执行结果如下：标明rownum不会因为排序而改变。

那么正确的做法是进行子查询

 select * 
    from (select rownum,empno,ename,sal 
    from emp 
    order by sal desc)
    Where rownum<=3;//这里的rownum是新查询表的伪列，是按照薪水排序的；

二、使用rownum进行分页查询

例子：

select r,empno,ename,sal from 
(select rownum r,empno,ename,sal from  
（select  rownum,empno,ename,sal
    from emp
    order by sal desc) e1
  where rownum<=8) e2
where r>=5;//注：这里的r不是e2表的行号，也不是e2表的伪列，而是e2表的第一列，所以可以使用>=

---

---

mysql分页

是用limit函数

取前5条数据

select * from table_name limit 0,5

或者

select * from table_name limit 5

查询第11到第15条数据

select * from table_name limit 10,5

limit关键字的用法：

LIMIT [offset,] rows

offset指定要返回的第一行的偏移量（从多少条开始查），rows第二个指定返回行的最大数目（最多查询多少条）。初始行的偏移量是0(不是1)。

数据量在多或者少的时候的解决方法
limit 基本实现方式
一般情况下，客户端通过传递 pageNo（页码）、pageSize（每页条数）两个参数去分页查询数据库中的数据，在数据量较小（元组百/千级）时使用 MySQL自带的 limit 来解决这个问题：

原因/缺点: 全表扫描,速度会很慢 且 有的数据库结果集返回不稳定(如某次返回1,2,3,另外的一次返回2,1,3). Limit限制的是从结果集的M位置处取出N条输出,其余抛弃.

收到客户端{pageNo:1,pagesize:10} 
select * from table limit (pageNo-1)*pageSize, pageSize;

收到客户端{pageNo:5,pageSize:30} 
select * from table limit (pageNo-1)*pageSize,pageSize;

建立主键或者唯一索引
在数据量较小的时候简单的使用 limit 进行数据分页在性能上面不会有明显的缓慢，但是数据量达到了 万级到百万级 sql语句的性能将会影响数据的返回。这时需要利用主键或者唯一索引进行数据分页；

原因: 索引扫描,速度会很快. 有朋友提出: 因为数据查询出来并不是按照pk_id排序的，所以会有漏掉数据的情况，只能方法3

假设主键或者唯一索引为 good_id 
收到客户端{pageNo:5,pagesize:10} 
select * from table where good_id > (pageNo-1)*pageSize limit pageSize; 
–返回good_id为40到50之间的数据

基于数据再排序
当需要返回的信息为顺序或者倒序时，对上面的语句基于数据再排序。order by ASC/DESC 顺序或倒序 默认为顺序

原因: 索引扫描,速度会很快. 但MySQL的排序操作,只有ASC没有DESC(DESC是假的,未来会做真正的DESC,期待…).

select * from table where good_id > (pageNo-1)*pageSize 
order by good_id limit pageSize; 
–返回good_id为40到50之间的数据,数据依据good_id顺序排列

对于这边我有一个疑问！如果主键或者索引不连续的话，查出来的数据不就会出现重复吗？坐等大神解惑！！！！！！困惑如下：

select * from table where good_id > (pageNo-1)*pageSize 
order by good_id limit pageSize;
//数据主键1，2，无，无，无，6，7，8，无，无，无
//收到客户端{pageNo:1,pagesize:5} ---1，2，6，7，8
//收到客户端{pageNo:2,pagesize:5} ---6，7，8
//第一页和第二页不都是出现了6，7，8吗？？？

本文引用自：

https://www.cnblogs.com/pinganzi/p/6645318.html
https://blog.csdn.net/starleejay/article/details/78802610
https://www.cnblogs.com/zhaotiancheng/p/6262635.html
https://blog.csdn.net/Accept7/article/details/77982629