内容摘录来源：MSSQL123 ，lujun9972.github.io/blog/2018/03/13/如何编写bash-completion-script/
一、先公布下结论：
1、如果分页排序字段是聚集索引，完全没必要对索引分页再查询数据，因为索引就是数据本身；
2、如果是非聚集索引，先对索引分页，然后再利用索引去查询数据，先分页索引确实可以减少扫描的范围；
3、如果经常按照2中的方式查询，也就是按照非聚集索引排序查询，强烈建议直接在该列上建立聚集索引；
二、MySQL经典的分页“优化”做法：
1、若在id上建立聚集索引，随着m的增大，查询同样多的数据，会越来越慢；
分页查询sql语句：select * from t order by id limit m,n ；
优化后的查询语句： select * from t inner join (select id from t order by id limit m,n)t1 on t1.id = t.id；
查询结果证明，优化后的没有卵用；
分析原因：排序列为聚集索引列的情况下，两者都是按照索引顺序扫描表，来查询符合条件的数据；后者虽然是先驱动一个子查询，然后再用子查询的结果驱动主表，但是子查询并没有改变“顺序扫描表，来查询符合条件的数据的”做法，当前情况下，甚至改写后的做法显得画蛇添足。
解决办法：mysql中也有类似于sqlserver中的正向（forwarded）和反向扫描（backward）的做法。如果对于靠后的数据，采用反向扫描，应该就可以很快找到这个部分数据，然后对找到的数据在再次排序（asc），查询结果是一样的（其实是借鉴了B-tree索引的数据结构）。
查询sql语句：select * from ( select * from test_table1 order by id desc limit 99980,20 ) t order by id;
实时证明，牛车直接变火箭了！换个角度考虑，当我们查字典时，若要查“张”字，肯定是直接翻到“Z”开头的去查，肯定不是从字母“A”开始翻吧。数据库也是人设计的，他们的解决方案，通常都是用现实生活中，小学生都能想明白的方案。
2、我们来了解下B-tree索引的数据结构，作者的这俩张图，灰常流弊：
如下图，当查询的数据“靠后”的时候，实际上是偏离在B树索引的一个方向，如下两个截图所示的目标数据其实平衡树上的数据，没有所谓的“靠前”与“靠后”，“靠前”与“靠后”都是相对于对方来说的，或者说是从扫描的方向上来看的从一个方向上看“靠后的”数据，从一个方向看就是“靠前的”，前后不是绝对的。
上面的分页优化方案就是根据这俩张图得出来的；
3、当我们以非聚集索引列作为排序字段时：
优化前sql语句：select * from test_table1 order by id_2 asc limit 4900000,20;执行时间为1分钟多一点，暂且认其为60秒；
优化后sql语句：select t1.* from test_table1 t1 inner join (select id from test_table1 order by id_2 limit 4900000,20)t2 on t1.id = t2.id;执行时间1.67秒，查询速度提高了40倍；
分析原因：可以简单理解为优化前的sql执行时做全表扫描之后，然后重新按照id_2排序，最后取最前20条数据；全表扫描就是一个非常耗时的过程，排序也是一个非常大的代价，因此表现为性能非常的低下。优化后的sql 语句的执行计划，是首先在子查询中，按照id_2上的索引顺序扫描，然后用符合条件的主键Id去表中查询数据。这样的话，避免了查询出来大量的数据然后重新排序（Using filesort）。
结论：排序列为非聚集索引列的时候，改写后的sql才能提升分页查询的效率。