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

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

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

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

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

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

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

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

优化策略

1. 延迟关联 (Deferred Join)

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

• 实现方式

  -- 先通过覆盖索引快速定位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值极大时性能仍会下降。

2. 键集分页 (Keyset Pagination)

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

• 实现方式

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

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

• 优点：查询性能恒定，不受分页深度影响，速度极快。

• 缺点：无法直接跳转到指定页码，仅适用于“上一页/下一页”或无限滚动场景。需要一个唯一且有序的排序列。

3. 业务限制

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

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

总结

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