企业官网建设流程全解析

一、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万条索引记录，所以是缓解方案，不是深分页的根本解决方案