SQL分页查询慢的根源在于OFFSET导致全表扫描与排序，优化需减少扫描行数、避免全表排序、绕过OFFSET线性成本；推荐游标分页（基于单调字段如ID或时间）、分区裁剪、缓存高频结果等策略。
SQL分页查询慢，核心问题往往不是“LIMIT OFFSET”本身，而是数据库在跳过大量数据时仍要扫描、排序甚至临时表处理。优化关键在于减少扫描行数、避免全表排序、绕过OFFSET的线性成本。
用游标分页（Cursor-based Pagination）替代OFFSET
适用于按时间、ID等严格单调字段排序的场景（如最新订单、用户动态）。它不依赖跳过多少行，而是记住上一页最后一条记录的值，下一页直接查“大于该值”的数据。
- 传统写法（慢）：red">SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 10000 —— 数据库仍需定位前10000条再取20条
- 游标写法（快）：SELECT * FROM orders WHERE created_at —— 索引可快速定位，几乎不扫描无关行
- 注意：必须有唯一且有序的字段（推荐组合索引如 (status, created_at, id)），并确保前端传回上一页末尾的created_at和id防重复
覆盖索引 + 主键关联减少回表
当分页字段和查询字段不一致时（比如按create_time排序，但要查user_id, amount, remark），数据库常需先走索引排序，再回表查完整行——OFFSET越大，回表越频繁，I/O压力越高。
- 建覆盖索引：CREATE INDEX idx_time_id ON orders (created_at DESC, id) —— 满足排序+快速定位主键
- 改写查询为两层：先用覆盖索引查出ID列表，再JOIN原表取详情
SELECT o.* FROM orders o INNER JOIN (SELECT id FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 10000) t ON o.id = t.id - 优点：外层JOIN只回表20次；缺点：OFFSET仍存在，适合中等偏大偏移（如几万），超百万建议切游标
物理分表 or 时间分区降低单表规模
如果总数据量达千万级以上，单表分页再怎么优化也难扛住高并发OFFSET。此时应从数据架构入手，让“分页”发生在更小的数据集上。
- 按月/季度分表：orders_202404、orders_202405，查询时明确指定月份，OFFSET自然变小
- 用MySQL 8.0+或PostgreSQL的时间范围分区，查询带WHERE create_time >= '2024-05-01'可自动裁剪分区
- 配合业务逻辑：后台“近3个月订单分页”就只查对应分区/子表，避免触碰历史冷数据
缓存高频分页结果（谨慎使用）
对实时性要求不高、排序规则固定、访问集中的分页（如商品类目TOP100榜单），可将分页结果缓存到Redis，格式如page:category:100:1 → [id1,id2,...]。
- 适用场景：后台运营看板、排行榜、配置类列表
- 注意点：设置合理过期时间；更新数据后主动清理相关页缓存；避免缓存“深度分页”（如第1000页），命中率低还占内存
- 不推荐用于用户个人数据分页（如“我的订单”），因个性化强、缓存键爆炸、一致性难保证
基本上就这些。真正高效的分页不是调优一句SQL，而是结合业务排序逻辑、数据分布特征和访问模式，选对策略：游标适合流式场景，覆盖索引+ID关联适合中等偏移，分表/分区是数据量过大时的必选项。别迷信OFFSET，它只是最简单的写法，不是最优解。
