MySQL中的limit和offset

limit x, y：表示跳过x个数据读取y个数据

limit x offset y：表示跳过y个数据读取x个数据，offset表示偏移量

limit x：表示从头开始读取x个数据，相当于limit 0，x

在写 select 语句的时候，使用 limit, offset 可能就像是我们吃饭喝水一样自然了。

刚开始工作的时候也经常听前辈们教导：使用 limit, offset，当 offset 变大的时候执行效率会越来越低。

相信在前辈们的言传身教，和自己的实战过程中，大家也都知道了为什么会这样。

因为 select 在执行过程中，对于存储引擎返回的记录，经过 server 层的 WHERE 条件筛选之后，符合条件的前offset 条记录，会被直接无情的抛弃，直到符合条件的第 offset + 1 条记录，才开始发送给客户端，发送了 limit 条记录之后，查询结束。

虽然知道了是什么，也知道了为什么，但是我也一直好奇底层是怎么实现的，所以今天我们来扒一扒它的庐山真面目。

先来简单的回顾一下 select 语句中 limit, offset 的语法，MySQL 支持 3 种形式：

在读取数据的过程中，对于符合条件的前offset 条记录，会直接忽略，不发送给客户端，从符合条件的第 offset + 1 条记录开始，发送 limit 条记录给客户端。

所以，server 层实际上需要从存储引擎读取offset + limit 条记录，源码里也是这么实现的，语法解析阶段，在验证了 offset 和 limit 都是大于等于 0 的整数之后，就把 offset + limit 的计算结果保存到一个叫做 select_limit_cnt 的属性里，offset 也会保存到一个叫做 offset_limit_cnt 的属性里。

来到发送数据阶段，此时的记录已经通过了 WHERE 条件的筛选，接下来就是判断这条记录是不是要发送给客户端。

第 1 步

因为 offset 已经保存到offset_limit_cnt 中了，先来判断 offset_limit_cnt 是否大于 0，如果大于 0，这条记录就会被抛弃了，不发送给客户端；如果等于 0，记录就具备了发送给客户端的资格了，然后接着进入 第 2 步 。

第 2 步

来到这一步，记录就具备了发送给客户端的资格了，至于要不要发，就看客户端想不想要它了，而客户端想不想要它，取决于select_limit_cnt 。

所以，在这一步要判断 已发送记录数量 （send_records）和 需要发送记的录数量 （select_limit_cnt）之间的关系，如果已发送记录数量 大于等于 需要发送的记录数量，则结束查询，否则就接着进入第 3 步。

第 3 步

在这里，记录愉快的等待着被发送给客户端。

既然在offset 变大之后，使用 limit, offset 效率越来越低，那应该怎么办呢？对于实战经验丰富的小伙伴来说，这是相当简单了，但是以防万一刚看到本文的小伙伴是刚刚开始用 SQL 写 Bug，所以还是要大概的写一下的。

以一个 SQL 为例：

为了取到 10 条记录，要先找到 8888 条记录，然后取到需要的 10 条，前面 8888 条记录都白找了，太浪费了，可以这样修改一下：

LAST_MAX_ID 是上一次执行 SQL 时读取到的 主键 ID 的最大值，如果是第一次执行语句， LAST_MAX_ID = 0 。

不过这种方案也有个问题，不支持跳着翻页，只支持顺序翻页（就是每次都点 下一页 的这种）。

如果要支持跳着翻页，怎么办？

只用 MySQL 这把锤子显然有点不够用了，还要再找一把锤子（Redis），可以把符合条件的记录的 主键 ID 都读取出来，存入到 Redis 的有序集合（zset）中，用 zset 相应的函数读取到某一页应该展示的数据对应的那些 主键 ID ，然后用这些主键 ID 去 MySQL 中查询对应的数据，从而用两把锤子间接的实现了分页功能。

当然，这个方案也是有适用场景的，比如，这个方案明显就不适用于这些场景：符合条件的记录非常非常多导致存主键 ID 到 Redis 要占用很大的内存、记录更新频繁导致存主键 ID 的缓存经常被清除。如果碰到更复杂的场景，就要结合业务具体情况具体分析了

---