MySQL深分页慢问题及性能优化

在数据驱动的应用中，分页是不可或缺的功能。然而，当数据量达到百万甚至千万级别时，传统基于 LIMIT OFFSET 的分页方式会遭遇严重的性能瓶颈，即"深分页"问题。本文将剖析其根源并提供主流的优化策略。

问题根源：`LIMIT OFFSET` 为何会慢？

我们最常用的分页查询语句如下：

sql 复制代码

-- 查询第10001页，每页10条数据
SELECT * FROM products ORDER BY id LIMIT 10 OFFSET 100000;

这条SQL的执行逻辑并非直接定位到第100,001条记录。MySQL的实际处理过程是：

从存储引擎中读取满足条件的前 100010 (OFFSET + LIMIT) 条记录。
在服务层（Server Layer）对这些记录进行排序。
抛弃前面的 100000 条记录。
返回最终的 10 条记录。

OFFSET 值越大，MySQL需要扫描、加载并最终抛弃的行数就越多，这导致了巨大的I/O和CPU资源浪费，是性能下降的直接原因。

优化策略

1. 延迟关联 (Deferred Join)

延迟关联的核心思想是先通过覆盖索引快速定位到目标页的主键ID，然后再关联原表获取完整的行数据，从而减少对主表数据的扫描。

实现方式

sql 复制代码

-- 先通过覆盖索引快速定位ID，再进行关联
SELECT p1.*
FROM products AS p1
INNER JOIN (
    -- 子查询仅在索引上操作，速度很快
    SELECT id FROM products ORDER BY id LIMIT 10 OFFSET 100000
) AS p2 ON p1.id = p2.id;

优点：保留了跳转任意页面的功能，性能相较于原始方法有显著提升。
缺点：SQL语句更复杂；当OFFSET值极大时性能仍会下降。

键集分页，或称"书签"法，是目前性能最优的方案。它摒弃了OFFSET，通过上一页最后一条记录的唯一键值来定位下一页的起始位置。

实现方式

假设我们按自增id排序，上一页返回的最后一条记录id为100000。

sql 复制代码

-- 不使用OFFSET，而是利用上一页的id进行定位
SELECT * FROM products
WHERE id > 100000
ORDER BY id ASC
LIMIT 10;

优点：查询性能恒定，不受分页深度影响，速度极快。
缺点：无法直接跳转到指定页码，仅适用于"上一页/下一页"或无限滚动场景。需要一个唯一且有序的排序列。

3. 业务限制

从产品层面限制用户能够访问的最大页数（例如100页）。在多数场景下，用户很少会浏览非常靠后的页面，引导用户使用更精确的筛选条件是更有效的方式。

优点：实现简单，从根本上规避了技术难题。
缺点：牺牲了部分功能，不适用于必须允许访问所有数据的场景。

总结

策略	优点	缺点	适用场景
延迟关联	功能完整，性能提升显著	SQL复杂，深度分页仍有瓶颈	需要跳转页码的传统分页
键集分页	性能最佳且稳定	无法跳页	无限滚动、上一页/下一页
业务限制	实现简单，规避问题	功能受限	搜索结果等多数常规列表

结论：在设计分页功能时，应优先考虑键集分页 方案以获得最佳性能。如果必须支持跳转任意页码，延迟关联是一个有效的折中选择。根据实际业务需求选择最合适的策略，是解决深分页问题的关键。

MySQL深分页慢问题及性能优化

问题根源：LIMIT OFFSET 为何会慢？

优化策略

1. 延迟关联 (Deferred Join)

2. 键集分页 (Keyset Pagination)

3. 业务限制

总结

问题根源：`LIMIT OFFSET` 为何会慢？