MySQL使用OFFSET和LIMIT带来的问题

Posted 2021-04-01 新工技术专栏

问题引入

    如果你是做过后台开发或数据库架构的Programmer，你可能是这样分页的：

    如果你真的是这么分页，那么我不得不抱歉地说，你这样做是错的。

    对于简单的小型应用程序和数据量不是很大的工程来说，这种方法是可以对付的，但是如果给你千百万条甚至更大的数据呢？

    今天我们将探讨已经被广泛使用的分页方式存在的问题，以及如何实现高性能分页。

    使用OFFSET 和 LIMIT 进行少量数据的分页查询是没有问题的。

    但是，当数据库里的数据量超过服务器内存能够存储的能力，并且需要对所有数据进行分页，问题就会出现。

为了实现分页，每次收到分页请求时，数据库都需要进行低效的全表扫描。

全表扫描 ：就是在数据库中从上往下逐行进行检索，分别检索表中每行记录的同时进行判断效率十分慢，需要进行大量的磁盘IO操作，并且从磁盘到内存的传输开销也十分巨大。

    假如，如果你有 10 亿个用户，OFFSET 是 5 亿，那么它需要获取所有这些记录，将它们放入内存，然后获取 LIMIT 指定的 20 条结果。

    也就是说，为了获取一页的数据：

    10万行中的第 5万行到第 5万零 20行

    需要先获取 5 万行。这么做是多么低效？

    现在你应该知道这背后都发生了什么：OFFSET 越高，查询时间就越长。

你应该这样做：

这是一种基于指针的分页。

    你要在本地保存上一次接收到的主键 (通常是一个 ID) 和 LIMIT，而不是 OFFSET 和 LIMIT，那么每一次的查询可能都与此类似。

    为什么？因为通过显式告知数据库最新行，数据库就确切地知道从哪里开始搜索（基于有效的索引），而不需要考虑目标范围之外的记录。

比较这个查询：

和优化的版本：

    返回同样的结果，第一个查询使用了 12.80 秒，而第二个仅用了 0.01 秒。

    要使用这种基于游标的分页，需要有一个惟一的序列字段 (或多个)，比如惟一的整数 ID 或时间戳，但在某些特定情况下可能无法满足这个条件。

    我的建议是，不管怎样都要考虑每种解决方案的优缺点，以及需要执行哪种查询。

如果需要基于大量数据做查询操作，Rick James 的文章提供了更深入的指导。

    如果我们的表没有主键，比如是具有多对多关系的表，那么就使用传统的 OFFSET/LIMIT 方式，只是这样做存在潜在的慢查询问题。我建议在需要分页的表中使用自动递增的主键，即使只是为了分页。