MySQL 分页优化中的 “ INNER JOIN方式优化分页算法 ” 到底在什么情况下会生效？

最近无意间看到一个 MySQL 分页优化的测试案例，并没有非常具体地说明测试场景的情况下，给出了一种经典的方案。因为现实中很多情况都不是固定不变的，能总结出来通用性的做法或者说是规律，是要考虑非常多的场景的；同时，面对能够达到优化的方式要追究其原因，同样的做法，换了个场景，达不到优化效果的，还要追究其原因。

个人对此场景在不用情况表示怀疑，然后自己测试了一把，果然发现一些问题，同时也证实了一些预期的想法。

本文就 MySQL 分页优化，从最最简单的情况出发，来做一个简单的分析。

另：本文测试环境是最最低配置的云服务器，相对来说服务器硬件环境有限，不过对于不同的语句（写法）应该是“平等的”。

20170916补充:

想想用脚趾头就能明白：

如果分页排序字段是聚集索引，完全没必要对索引分页再查询数据，因为索引就是数据本身；
如果是非聚集索引，先对索引分页，然后再利用索引去查询数据，先分页索引确实可以减少扫描的范围；
如果经常按照2中的方式查询，也就是按照非聚集索引排序查询，那么为什么不在该列上建立聚集索引呢。

MySQL 经典的分页“优化”做法

MySQL 分页优化中，有一种经典的问题，在查询越“靠后”的数据越慢（取决于表上的索引类型，对于B树结构的索引，SQL Server 中也一样）。