使用limit,offset分页场景时为什么会慢

从一个问题说起

五年前在腾讯的时候，发现分页场景下，mysql请求速度非常慢。数据量只有10w的情况下，select xx from 单机大概2，3秒。

我就问我师父为什么，他反问“索引场景，mysql中获得第n大的数，时间复杂度是多少？”

答案的追寻

确认场景

假设status上面有索引。select * from table where status = xx limit 10 offset 10000。

会非常慢。数据量不大的情况就有几秒延迟。

小白作答

那时候非常有安全感，有啥事都有师父兜着，反正技术都是组里最差的，就瞎猜了个log(N)，心想找一个节点不就是log(N)。自然而然，师父让我自己去研究。

这一阶段，用了10分钟。

继续解答

仔细分析一下，会发现通过索引去找很别扭。因为你不知道前100个数在左子树和右子数的分布情况，所以其是无法利用二叉树的查找特性。

通过学习，了解到mysql的索引是b+树。

看了这个图，就豁然开朗了。可以直接通过叶子节点组成的链表，以o(n)的复杂度找到第100大的树。但是即使是o(n)，也不至于慢得令人发指，是否还有原因。

这一阶段，主要是通过网上查资料，断断续续用了10天。

系统学习

这里推荐两本书，一本《MySQL技术内幕 InnoDB存储引擎》，通过他可以对InnoDB的实现机制，如mvcc，索引实现，文件存储会有更深理解。

第二本是《高性能MySQL》，这本书从着手使用层面，但讲得比较深入，而且提到了很多设计的思路。

两本书相结合，反复领会，mysql就勉强能登堂入室了。

这里有两个关键概念：

即使前10000个会扔掉，mysql也会通过二级索引上的主键id,去聚簇索引上查一遍数据，这可是10000次随机io，自然慢成哈士奇。

这里可能会提出疑问，为什么会有这种行为，这是和mysql的分层有关系，limit offset 只能作用于引擎层返回的结果集。换句话说，引擎层也很无辜，他并不知道这10000个是要扔掉的。

以下是mysql分层示意图，可以看到，引擎层和server层，实际是分开的。

直到此时，大概明白了慢的原因。这一阶段，用了一年。

触类旁通

此时工作已经3年了，也开始看一些源码。在看完etcd之后，看了些tidb的源码。无论哪种数据库，其实一条语句的查询，是由逻辑算子组成。

逻辑算子介绍

在写具体的优化规则之前，先简单介绍查询计划里面的一些逻辑算子。

选择，投影，连接（简称 SPJ） 是最基本的算子。其中 Join 有内连接，左外右外连接等多种连接方式。

select b from t1, t2 where t1.c = t2.c and t1.a > 5变成逻辑查询计划之后，t1 t2 对应的 DataSource，负责将数据捞上来。

上面接个 Join 算子，将两个表的结果按 t1.c = t2.c连接，再按 t1.a > 5 做一个 Selection 过滤，最后将 b 列投影。