MySQL limit分页的性能问题

今天在学习MyBatis分页插件的时候，在别人博客看到这样的一句话

 博客地址：https://www.cnblogs.com/kangoroo/p/7998433.html

当时看到这话觉得挺不可思议，觉得这不符合自己的认知。那就开始实际测试看看。

数据库有1000021条数据，id设为主键索引的情况下测试结果如下

alter table indextable add primary key(id)
show keys from indextable
reset query cache	 

explain select * from indextable	-- 查询1000012 用时2.437s type:ALL

explain select * from indextable limit 1000011,1	-- 查询1000012中的最后一条数据 用时0.333s type:ALL

explain select * from indextable limit 0,1000		-- 查询1000012中的前一千条数据 用时0.0008s type:ALL

explain select * from indextable limit 999012,1000	-- 查询1000012中的后一千条数据 用时0.321s type:ALL

reset query cache	-- 清空缓存

explain select -- 查询1000012中的后一千条数据 用时0.247s 主查询-type:eq_ref row=1 子查询-type:index Extra:Using inedx
  indextable.`id`,
  indextable.`name`,
  indextable.`sex`
from indextable
inner join (
	select id from indextable
	order by id limit 999012,1000
) tb_indextable 
on indextable.`id` = tb_indextable.`id`


explain select --  查询1000012中的最后一条数据 用时0.243s 主查询-type:const row=1 子查询-type:index Extra:Using inedx
  indextable.`id`,
  indextable.`name`,
  indextable.`sex`
from indextable
inner join (
	select id from indextable
	order by id limit 1000011,1
) tb_indextable 
on indextable.`id` = tb_indextable.`id`

 前四条的测试结果在我个人看来有两种结果，1.limit不是过滤1000021条数据取最后一条 2.limit是过滤1000021条数据取最后一条，但limit本身做了优化

对于这样的结果我们是不满意的。即便是查询中间的、后面的数据，我们都想像查询前N条数据快速，所以后面两条测试是一种优化方案。

建立索引，并且使查询语句使用索引，这是优化方案的思想。

当然，没有主键索引的情况下，优化方案是行不通的。结果如下：