场景：现在有一管理端后台系统，需要查看第8700页用户列表(假设存在这一页)信息。原来程序员写的sql如下SELECT scu.* FROM st_community_user scu ORDER BY scu.create_time DESC LIMIT 870000,100
这里附上总用户数
原来程序员写的sql查询时长
根据上图可以看出，查询时长为4.5s多，反应在页面上就是用户需要等待5s到6s才能打开这个页面，很明显是不能容忍的。
优化开始
这里稍加修改下sql，如下SELECT scu.user_id FROM st_community_user scu ORDER BY scu.create_time DESC LIMIT 870000,100
查询时长如下
如上图，很明显，查询时长降下来了。
原理分析：sql查询时，如果用到的索引语句中只包含了索引列(覆盖索引)，那么这种情况下查询很快。如上的样例中，查询结果本来是scu.*，改成scu.user_id，且user_id是主键，唯一索引。查询索引列(user_id)速度就会很快！
但是上述语句查询出的是用户id列表，而不是用户信息列表，完善sql如下SELECT scu_a.* FROM st_community_user scu_a,(SELECT scu.user_id FROM st_community_user scu ORDER BY scu.create_time DESC LIMIT 870000,100) scu_b WHERE scu_a.user_id = scu_b.user_id;
查询时长如下图
至此优化结束。