SQL深分页慢的根源是OFFSET需扫描跳过大量行，优化应采用游标分页（基于排序字段值范围查询）或延迟关联（先查ID再关联），并确保索引匹配排序顺序。
SQL分页查询慢，核心问题往往不是“LIMIT OFFSET”本身，而是数据库要先扫描跳过大量行才能拿到目标数据。尤其在百万级以上表、深分页（比如OFFSET 100000）时，性能断崖式下跌。优化关键：避免全表扫描跳过，改用“游标分页”或“延迟关联”，同时确保索引真正生效。
为什么 OFFSET 越大越慢？
比如 SELECT * FROM orders ORDER BY create_time DESC LIMIT 20 OFFSET 100000，MySQL 必须先按 create_time 排序，再逐行数满 100000 条，才取后面 20 条——前面 10 万行全做了无效扫描。
常见误区：
- 加了 ORDER BY 字段的索引就一定快？不一定。如果 SELECT * 包含未索引字段，InnoDB 还得回表；
- 用主键排序分页就安全？OFFSET 大了照样慢。
推荐方案一：游标分页（最有效，适合“下一页”场景）
不依赖 OFFSET，而是记住上一页最后一条的排序值（如时间戳或ID），下一页直接查“比它更小/更大的记录”。要求排序字段唯一且有索引（推荐用自增主键或带唯一约束的时间+ID组合）。
- 第一页：SELECT * FROM posts ORDER BY id DESC LIMIT 20
- 第二页（已知上一页最后 id = 10050）：SELECT * FROM posts WHERE id
- 优势：每次都是索引范围查询，复杂度 O(log N)，100万条也能毫秒响应
- 注意：不能跳页（如直接跳到第100页），也不支持倒序“上一页”（需额外缓存上一页最小值）
推荐方案二：延迟关联（兼容跳页，适合管理后台）
把分页逻辑“拆开”：先用覆盖索引快速定位 ID，再用这些 ID 回查完整数据。大幅减少回表和扫描行数。
原低效写法：
SELECT * FROM users ORDER BY reg_time DESC LIMIT 20 OFFSET 50000
优化后：
SELECT u.* FROM users u
INNER JOIN (SELECT id FROM users ORDER BY reg_time DESC LIMIT 20 OFFSET 50000) t
ON u.id = t.id;
说明：
- 子查询只查 id（假设 id 和 reg_time 都在联合索引里），走索引，不回表；
- 主查询只用主键 ID 关联，回表次数从 50020 次降到 20 次；
- 索引建议：INDEX(reg_time, id)（顺序很重要，让 ORDER BY + LIMIT 走索引）
避坑提醒：这些细节决定成败
- ORDER BY 字段必须有索引，且索引顺序要匹配排序方向（如 ORDER BY a ASC, b DESC，索引也要对应）
- 避免在分页字段上用函数或表达式，例如 ORDER BY DATE(create_time) —— 索引失效
- 深分页慎用 COUNT(*) 总数统计，可改用估算（如 SHOW TABLE STATUS）或业务妥协（“只显示前N页”）
- PostgreSQL 用户可用 cursor + FETCH NEXT 原生支持游标分页，更简洁
基本上就这些。游标分页适合 Feed 流、日志列表等线性浏览场景；延迟关联适合需要任意跳页的后台系统。选对方法，分页从秒级降到毫秒级很常见。
