最近无意间看到一个 MySQL 分页优化的测试案例，并没有非常具体地说明测试场景的情况下，给出了一种经典的方案。因为现实中很多情况都不是固定不变的，能总结出来通用性的做法或者说是规律，是要考虑非常多的场景的；同时，面对能够达到优化的方式要追究其原因，同样的做法，换了个场景，达不到优化效果的，还要追究其原因。
个人对此场景在不用情况表示怀疑，然后自己测试了一把，果然发现一些问题，同时也证实了一些预期的想法。
本文就 MySQL 分页优化，从最最简单的情况出发，来做一个简单的分析。
另：本文测试环境是最最低配置的云服务器，相对来说服务器硬件环境有限，不过对于不同的语句（写法）应该是“平等的”。
20170916补充:
想想用脚趾头就能明白：
如果分页排序字段是聚集索引，完全没必要对索引分页再查询数据，因为索引就是数据本身；如果是非聚集索引，先对索引分页，然后再利用索引去查询数据，先分页索引确实可以减少扫描的范围；如果经常按照2中的方式查询，也就是按照非聚集索引排序查询，那么为什么不在该列上建立聚集索引呢。
MySQL 经典的分页“优化”做法
MySQL 分页优化中，有一种经典的问题，在查询越“靠后”的数据越慢（取决于表上的索引类型，对于B树结构的索引，SQL Server 中也一样）。
select * from t order by id limit m,n。
也即随着M的增大，查询同样多的数据，会越来越慢。面对这一问题，于是就产生了一种经典的做法，类似于（或者变种）如下的写法：先把分页范围内的id单独找出来，然后再跟基表做关联，最后查询出来所需要的数据。
select * from t
inner join (select id from t order by id limit m,n)t1 on t1.id = t.id
这种做法是不是总是生效的，或者说是在什么情况下后者才能到达到优化的目的？有没有做了改写之后无效甚至变慢的情况？
与此同时，绝大多数查询都是有筛选条件的，如果有筛选条件的情况，SQL 语句就变成了：
select * from t where *** order by id limit m,n