互联网公司都怎么实现分页的，拿 MySQL 使劲Limit？

本文主要是介绍互联网公司都怎么实现分页的，拿 MySQL 使劲Limit？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

刷网站的时候，我们经常会遇到需要分页查询的场景。

我们很容易能联想到可以用mysql实现。

假设我们的建表sql是这样的

mysql建表sql

建表sql大家也不用扣细节，只需要知道 id是主键，并且在user_name建了个非主键索引 就够了，其他都不重要。

为了实现分页。

很容易联想到下面这样的sql语句。

select * from page order by id limit offset, size;

比如一页有10条数据。

user表数据库原始状态

第一页就是下面这样的sql语句。

select * from page order by id limit 0, 10;

第一百页就是

select * from page order by id limit 990, 10;

那么问题来了。

用这种方式，同样都是拿10条数据，查第一页和第一百页的查询速度是一样的吗？为什么？

两种limit的执行过程

上面的两种查询方式。对应 limit offset, size 和 limit size 两种方式。

而其实 limit size ，相当于 limit 0, size 。也就是从0开始取size条数据。

也就是说，两种方式的 区别在于offset是否为0。

我们先来看下limit sql的内部执行逻辑。

Mysql架构

mysql内部分为 server层 和 存储引擎层 。一般情况下存储引擎都用innodb。

server层有很多模块，其中需要关注的是 执行器 是用于跟存储引擎打交道的组件。

执行器可以通过调用存储引擎提供的接口，将一行行数据取出，当这些数据完全符合要求（比如满足其他where条件），则会放到 结果集 中，最后返回给调用mysql的 客户端（go、java写的应用程序） 。

我们可以对下面的sql先执行下 explain 。

explain select * from page order by id limit 0, 10;

可以看到，explain中提示 key 那里，执行的是 PRIMARY ，也就是走的 主键索引 。

分页查询offset=0

主键索引本质是一棵B+树，它是放在innodb中的一个数据结构。

我们可以回忆下，B+树大概长这样。

B+树结构

在这个树状结构里，我们需要关注的是，最下面一层节点，也就是 叶子结点 。而这个叶子结点里放的信息会根据当前的索引是 主键还是非主键 有所不同。

如果是 主键索引 ，它的叶子节点会存放完整的行数据信息。
如果是 非主键索引 ，那它的叶子节点则会存放主键，如果想获得行数据信息，则需要再跑到主键索引去拿一次数据，这叫回表。

比如执行

select * from page where user_name = "小白10";

会通过非主键索引去查询 user_name 为" 小白10 "的数据，然后在叶子结点里找到" 小白10 "的数据对应的 主键为10 。

此时回表到 主键索引 中做查询，最后定位到 主键为10的行数据 。

回表

但不管是主键还是非主键索引，他们的叶子结点数据都是 有序的 。比如在主键索引中，这些数据是根据主键id的大小，从小到大，进行排序的。

基于主键索引的limit执行过程

那么回到文章开头的问题里。

当我们去掉explain，执行这条sql。

select * from page order by id limit 0, 10;

上面select后面带的是星号 *，也就是要求获得行数据的 所有字段信息。

server层会调用innodb的接口，在innodb里的主键索引中获取到第0到10条 完整行数据 ，依次返回给server层，并放到server层的结果集中，返回给客户端。

而当我们把offset搞离谱点，比如执行的是

select * from page order by id limit 6000000, 10;

server层会调用innodb的接口，由于这次的offset=6000000，会在innodb里的主键索引中获取到第0到（6000000 + 10）条 完整行数据 ，返回给server层之后根据offset的值挨个抛弃，最后只留下最后面的size条，也就是10条数据，放到server层的结果集中，返回给客户端。

可以看出，当offset非0时，server层会从引擎层获取到 很多无用的数据 ，而获取的这些无用数据都是要耗时的。

因此，我们就知道了文章开头的问题的答案， mysql查询中 limit 1000,10 会比 limit 10 更慢。原因是 limit 1000,10 会取出1000+10条数据，并抛弃前1000条，这部分耗时更大

那这种case有办法优化吗？

可以看出，当offset非0时，server层会从引擎层获取到很多无用的数据，而当select后面是*号时，就需要拷贝完整的行信息， 拷贝完整数据 跟 只拷贝行数据里的其中一两个列字段 耗时是不同的，这就让原本就耗时的操作变得更加离谱。

因为前面的offset条数据最后都是不要的，就算将完整字段都拷贝来了又有什么用呢，所以我们可以将sql语句修改成下面这样。

select * from page  where id >=(select id from page  order by id limit 6000000, 1) order by id limit 10;

上面这条sql语句，里面先执行子查询 select id from page order by id limit 6000000, 1 , 这个操作，其实也是将在innodb中的主键索引中获取到 6000000+1 条数据，然后server层会抛弃前6000000条，只保留最后一条数据的id。

但不同的地方在于，在返回server层的过程中，只会拷贝数据行内的id这一列，而不会拷贝数据行的所有列，当数据量较大时，这部分的耗时还是比较明显的。

在拿到了上面的id之后，假设这个id正好等于6000000，那sql就变成了

select * from page  where id >=(6000000) order by id limit 10;

这样innodb再走一次 主键索引 ，通过B+树快速定位到id=6000000的行数据，时间复杂度是lg(n)，然后向后取10条数据。

这样性能确实是提升了，亲测能快一倍左右，属于那种耗时从3s变成1.5s的操作。

这······

属实有些杯水车薪，有点搓，属于没办法中的办法。

基于非主键索引的limit执行过程

上面提到的是主键索引的执行过程，我们再来看下基于 非主键索引 的limit执行过程。

比如下面的sql语句

select * from page order by user_name  limit 0, 10;

server层会调用innodb的接口，在innodb里的非主键索引中获取到第0条数据对应的主键id后，回表到主键索引中找到对应的完整行数据，然后返回给server层，server层将其放到结果集中，返回给客户端。

而当offset>0时，且offset的值较小时，逻辑也类似，区别在于，offset>0时会丢弃前面的offset条数据。

也就是说非主键索引的limit过程，比主键索引的limit过程，多了个回表的消耗。

但当offset变得非常大时，比如600万，此时执行explain。

非主键索引offset值超大时走全表扫描

可以看到type那一栏显示的是ALL，也就是 全表扫描 。

这是因为server层的 优化器 ，会在执行器执行sql语句前，判断下哪种执行计划的代价更小。

很明显，优化器在看到非主键索引的600w次回表之后，摇了摇头，还不如全表一条条记录去判断算了，于是选择了全表扫描。

因此，当limit offset过大时，非主键索引查询非常容易变成全表扫描。是真·性能杀手。

这种情况也能通过一些方式去优化。比如

select * from page t1, (select id from page order by user_name limit 6000000, 100) t2  WHERE t1.id = t2.id;

通过 select id from page order by user_name limit 6000000, 100 。先走innodb层的user_name非主键索引取出id，因为只拿主键id， 不需要回表 ，所以这块性能会稍微快点，在返回server层之后，同样抛弃前600w条数据，保留最后的100个id。然后再用这100个id去跟t1表做id匹配，此时走的是主键索引，将匹配到的100条行数据返回。这样就绕开了之前的600w条数据的回表。

当然，跟上面的case一样，还是没有解决要白拿600w条数据然后抛弃的问题，这也是非常挫的优化。

像这种，当offset变得超大时，比如到了百万千万的量级，问题就突然变得严肃了。

这里就产生了个专门的术语，叫 深度分页 。