1. 根据自增且连续的主键排序
使用条件：主键连续且自增 & 结果按照主键排序
select * from employees limit 90000,5;
理论上应该走主键索引, 为什么现在type是 all呢?
● 查询第9w行数据开始的5条数据时属于深度分页。
● limit 90000 5工作原理就是先读取前面90005行记录，舍弃前90000行记录，取5条想要的，
● 查询行数越大，偏移量越大，性能越差。
● 因此这条查询语句type 类型是all使用的全表扫描的方式
没有单独的order by表示通过主键取排序, 并且我们可以看到主键是自增且连续
优化
select * from employees where id > 90000 limit 5;
结论
优化后的 SQL 走了索引，且扫描的行数大大减少，执行效率更高。
但是，这条改写的SQL 主键连续且自增条件苛刻。 在很多场景不适用。 比如我们删除90002行记录, 那么查询90001开始的第行记录就会变成90001, 90003, 90004,90005,90006
且根据1.2的案例我们可以知道 SQL 是 order by 非主键的字段，按照上面说的方法改写会导致两条 SQL 的结果不一致. 所以这种改写得满足以下两个条件：
● 主键自增且连续
● 结果是按照主键排序的
2. 根据非主键字段排序
select * from employees ORDER BY name limit 90000,5;
分析结果中看到没有使用 name 字段索引（key 字段对应的值为 null）
扫描整个索引并查找到没索引的行(可能要遍历多个索引树)的成本比扫描全表的成本更高，所以优化器放弃使用索引。
优化
关键是让排序时返回的字段尽可能少，所以可以让排序和分页操作先查出主键，然后根据主键查到对应的记录，就是尽量使用覆盖索引减少回表的操作
select * from employees e inner join (select id from employees order by name limit 90000,5) ed
on e.id = ed.id;
结论
查询结果一样, 优化后查询效率更高. 原 SQL 使用的是 filesort 排序，而优化后的 SQL 使用的是索引排序
