深度分页慢的关键在OFFSET，MySQL需扫描并丢弃前N行；推荐游标分页，即用上一页最后排序字段值（如id>1058）替代OFFSET，并配合复合索引、覆盖索引、延迟关联等优化。

深度分页为什么慢？关键在 OFFSET

当执行 SELECT * FROM orders ORDER BY id LIMIT 100000, 20 时，MySQL 仍需扫描前 100000 行才能跳到目标位置。数据量越大，OFFSET 越大，性能越差——不是因为取 20 条慢，而是因为“扔掉”那 10 万行代价太高。

用主键/索引列替代 OFFSET：游标分页（推荐）

核心思路是：不依赖行号偏移，而记住上一页最后一条记录的排序字段值，下一页从该值之后开始查。

• 第一页：SELECT * FROM orders WHERE status = 1 ORDER BY id ASC LIMIT 20
• 第二页（假设第一页最大 id 是 1058）：SELECT * FROM orders WHERE status = 1 AND id > 1058 ORDER BY id ASC LIMIT 20
• 必须确保 ORDER BY 字段有索引（如 INDEX(status, id)），否则无法高效定位
• 游标值（如 id > 1058）要由前端传回，不能用 OFFSET 计算，避免漏数或重复

其他实用优化手段

单靠游标还不够？再加几层保障：

• 覆盖索引：只查需要的字段，避免回表。例如 SELECT id, order_no, amount FROM orders …，配合 INDEX(status, id, order_no, amount)
• 延迟关联：大表 JOIN 时，先用游标分页获取主键，再用 IN 关联详情。比如先查出 20 个 id，再 SELECT * FROM orders WHERE id IN (…)
• 禁止跳页：前端禁用“跳转到第 100 页”按钮，只提供“下一页/上一页”，保证游标链连续
• 时间范围兜底：对按时间排序的场景（如 created_at），可用 WHERE created_at > '2024-01-01' AND ... ORDER BY created_at DESC LIMIT 20，比纯 ID 游标更符合业务直觉

什么情况仍需慎用游标？

游标分页不是银弹：

• 用户需要随机跳页（如搜索后翻到第 50 页），游标无法直接支持，可结合 ES 或预计算页码映射
• 排序字段存在大量重复值（如多个订单 created_at 相同），需增加二级排序字段（如 ORDER BY created_at DESC, id DESC）确保唯一性
• 数据实时写入频繁且排序字段更新多（如 status 频繁变更），可能导致游标查询结果错乱，此时应考虑物化视图或读写分离+一致性快照