Mysql:分页有什么性能问题？如何去优化呢？

一、MySQL分页为什么会慢

常见分页：

SELECT *
FROM orders
ORDER BY id
LIMIT 1000000, 20;

LIMIT offset, size 表示跳过前 offset 条，再返回 size 条。上面的 SQL 不是直接跳到第 1000001 条，而是需要沿着结果顺序读取大量记录，跳过前 100 万条，只返回最后 20 条。页码越深，需要检查并丢弃的记录越多。

可以简单理解为：

LIMIT 0, 20          检查约20条
LIMIT 1000, 20       检查约1020条
LIMIT 1000000, 20    检查约1000020条

因此，传统分页的成本通常随着 offset 增大而增长。

二、分页的主要性能问题

1. 深分页扫描大量无用记录

SELECT *
FROM orders
ORDER BY id
LIMIT 1000000, 20;

真正返回20条，但前面100万条都属于无效工作，带来更多：

B+Tree叶子节点遍历；

Buffer Pool访问；

CPU条件判断；

磁盘I/O；

可能的回表查询。

2. 二级索引排序可能产生大量回表

假设有索引：

CREATE INDEX idx_created_at ON orders(created_at);

查询：

SELECT *
FROM orders
ORDER BY created_at
LIMIT 1000000, 20;

二级索引叶子节点主要保存：

(created_at, 主键id)

但 SELECT * 需要完整记录，所以可能通过主键到聚簇索引查询数据。InnoDB二级索引记录包含主键，完整行数据则存放在聚簇索引中。

深分页情况下，可能出现：

扫描大量二级索引记录
        ↓
通过主键回表
        ↓
丢弃前面的记录
        ↓
只返回20条

具体是否以及何时回表由执行计划决定。

3. 排序不能使用索引时出现 filesort

SELECT *
FROM orders
WHERE status = 1
ORDER BY amount
LIMIT 100000, 20;

如果没有合适索引，MySQL可能先找出符合条件的记录，再进行 filesort。即使最终只返回20条，也可能需要读取和处理大量候选记录。可以通过 EXPLAIN 的 Extra 是否出现 Using filesort 判断。

4. 分页结果可能不稳定

不写 ORDER BY：

SELECT * FROM orders LIMIT 20, 20;

数据库不保证每次返回顺序一致。

即使写了：

ORDER BY created_at

如果多条记录的 created_at 相同，它们之间的顺序仍不确定，应增加唯一字段：

ORDER BY created_at DESC, id DESC

MySQL官方文档也建议增加额外排序列，使顺序具有确定性。

三、优化一：建立匹配条件和排序的联合索引

查询：

SELECT id, user_id, status, created_at
FROM orders
WHERE user_id = 100
  AND status = 1
ORDER BY created_at DESC, id DESC
LIMIT 20;

建立索引：

CREATE INDEX idx_user_status_time_id
ON orders(user_id, status, created_at DESC, id DESC);

索引顺序可以理解为：

等值查询列 → 排序列 → 唯一排序列
user_id, status, created_at, id

这样MySQL可以先定位用户和状态，再按照索引顺序读取，减少扫描和额外排序。MySQL能够在索引顺序满足 ORDER BY 时避免 filesort

但要注意：

索引能够减少排序和过滤成本，却不能从根本上解决巨大 offset 带来的跳过成本。

四、优化二：游标分页，最推荐

也叫：

Keyset Pagination

Seek Pagination

基于最后一条记录分页

第一页：

SELECT *
FROM orders
WHERE user_id = 100
  AND status = 1
ORDER BY created_at DESC, id DESC
LIMIT 20;

记录最后一条数据：

created_at = '2026-08-01 10:00:00'
id = 5000

下一页：

SELECT *
FROM orders
WHERE user_id = 100
  AND status = 1
  AND (
       created_at < '2026-08-01 10:00:00'
       OR (created_at = '2026-08-01 10:00:00' AND id < 5000)
  )
ORDER BY created_at DESC, id DESC
LIMIT 20;

配合索引：

CREATE INDEX idx_user_status_time_id
ON orders(user_id, status, created_at DESC, id DESC);

执行过程变成：

从上一页最后位置附近定位
        ↓
继续读取20条

优点：

深度增加时性能比较稳定；

不需要跳过前面几十万条；

数据新增时不容易出现重复数据；

特别适合信息流、订单列表和滚动加载

缺点：

不能方便地直接跳到第10000页；

前端需要保存上一页最后一条记录的游标；

排序字段最好稳定且不允许为 NULL；

最好加入唯一字段 id，避免游标位置不唯一

五、优化三：延迟关联

如果业务必须使用页码和大 offset，可以先使用覆盖索引找到20个主键，再查询完整数据：

SELECT o.*
FROM orders AS o
JOIN (
    SELECT id
    FROM orders
    WHERE status = 1
    ORDER BY created_at DESC, id DESC
    LIMIT 1000000, 20
) AS p ON p.id = o.id
ORDER BY o.created_at DESC, o.id DESC;

配合索引：

CREATE INDEX idx_status_time_id
ON orders(status, created_at DESC, id DESC);

内部查询只读取索引中的小字段：

扫描覆盖索引 → 获得20个id → 只回表20次

它减少了大量无意义的回表，但仍然需要跳过100万条索引记录，所以是缓解方案，不是深分页的根本解决方案