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，优先想“怎么跳过扫描”，而不是“怎么跳过行数”。
