sql分页查询慢的核心是 OFFSET 导致线性扫描，应改用游标分页或延迟关联，并建立合适索引；避免大 OFFSET、提前过滤、合理使用缓存或物理分区。
SQL 分页查询慢，核心问题往往不是“LIMIT OFFSET”本身，而是 数据库 要先扫描并跳过前面大量数据。真正有效的优化，是绕开 OFFSET 的线性扫描，改用“游标分页”或“延迟关联”等策略，同时确保关键字段有合适索引。
避免大 OFFSET：用游标分页替代 LIMIT OFFSET
当页码很大（比如第 10000 页），select * FROM orders ORDER BY id LIMIT 20 OFFSET 200000会强制 mysql 扫描前 200000 行再取 20 条，效率急剧下降。游标分页用上一页最后一条记录的排序字段值作为条件，让查询直接定位起点：
- 第 1 页：SELECT * FROM orders WHERE status = 1 ORDER BY id ASC LIMIT 20
- 第 2 页（假设第 1 页最后 id 是 15678）：SELECT * FROM orders WHERE status = 1 AND id > 15678 ORDER BY id ASC LIMIT 20
注意：必须有确定的排序字段（推荐主键或唯一递增字段），且 WHERE 条件中其他过滤字段（如 status）也要加在游标条件里，避免数据错位。
覆盖索引 + 延迟关联：减少回表开销
如果分页字段和查询字段不统一（比如按 create_time 排序，但还要查 user_name、amount 等），全字段 SELECT 容易触发大量回表。可先用索引快速定位 ID，再二次 JOIN 获取详情：
- 第一步（走索引）：SELECT id FROM orders WHERE status = 1 ORDER BY create_time DESC LIMIT 20 OFFSET 1000
- 第二步（关联主表）：SELECT o.* FROM orders o INNER JOIN (上面子查询） t ON o.id = t.id
前提是 status + create_time 上有联合索引，这样第一步完全走索引，不访问数据行。
提前过滤，缩小分页基数
分页慢常因未加有效 WHERE 条件，导致在几百万行中分页。务必在 ORDER BY 前就用高区分度字段缩小结果集：
- 差：SELECT * FROM logs ORDER BY id DESC LIMIT 10 OFFSET 50000（全表扫描）
- 好：SELECT * FROM logs WHERE date >= ‘2024-06-01’ AND level = ‘Error’ ORDER BY id DESC LIMIT 10 OFFSET 50000（先过滤到几千行再分页）
记得为 date + level + id 建联合索引，让过滤和排序都能命中索引。
物理分页慎用：考虑 前端 分页或缓存
对实时性要求不高的列表（如后台运营报表），可将高频分页结果缓存（redis 或本地缓存），或一次性查出全部 ID 列表缓存，后续分页只查 ID 再按需加载详情。对超 大数据 量（千万级 +），也可考虑按时间 / 区域做物理分区，把单表拆成多个子表分而治之。
基本上就这些——不复杂但容易忽略。关键是别迷信 OFFSET，优先想“怎么跳过扫描”，而不是“怎么跳过行数”。
