SQL分页慢主因是OFFSET过大或排序字段无索引，游标分页（用WHERE+上页末值）可提升10倍性能；联合索引、覆盖索引、分表路由、热点页缓存为关键优化手段。

SQL分页查询慢，根本原因往往不是“数据量大”，而是偏移量（OFFSET）过大或排序字段缺乏有效索引。真实场景中，第10万页、每页20条的查询（OFFSET 2000000 LIMIT 20）可能耗时数秒甚至超时——这不是数据库不行，是写法没绕开B+树索引的天然限制。

用“游标分页”替代OFFSET/LIMIT（最有效）

适用于按时间、ID等单调字段排序的场景（如订单列表、日志流）。核心思路：不跳过前N行，而是记住上一页最后一条记录的排序值，下一页只查“比它更新/更大”的数据。

• 传统写法（慢）：SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 40000
• 游标写法（快）：SELECT * FROM orders WHERE created_at （假设上一页最后一条created_at是这个值）
• 关键点：必须给ORDER BY字段建索引（如INDEX(created_at)），且WHERE条件能命中索引范围扫描
• 注意：游标分页不支持直接跳转任意页，但对“下拉加载”“翻页浏览”完全够用，性能提升常达10倍以上

覆盖索引 + 主键回表，减少IO开销

当必须用OFFSET/LIMIT（如后台管理需跳转指定页码），优先让索引“扛住”排序和分页，避免全表扫描。

• 错误做法：只在status字段建索引，却ORDER BY create_time并SELECT * → 索引失效，回表次数爆炸
• 正确做法：建立联合索引INDEX(status, create_time, id)（顺序很重要），查询时先过滤status，再按create_time排序，最后用id回表取其他字段
• 更优：若只需展示id、title、create_time等少数字段，把它们全包含进索引（覆盖索引），彻底避免回表：INDEX(status, create_time, id, title)

物理分表 + 分页路由，拆解单表压力

单表超千万行后，即使有索引，OFFSET也会越来越慢。这时分页逻辑要和分表策略联动。

• 按时间分表（如orders_202501、orders_202502）：分页前先算目标页码落在哪个月份表，再在该表内分页，数据量直接降一个数量级
• 按ID哈希分表：查询时用WHERE user_id % 8 = ?定位分片，再结合本地OFFSET，避免跨分片合并排序
• 工具建议：ShardingSphere、MyCat可自动路由，但业务层仍需理解分页如何与分片键配合

缓存“热点页”，减少重复计算

用户最常看的是前100页（比如搜索结果、排行榜），这些页的SQL结果可缓存1–5分钟。

• 用Redis存储分页结果，key设计为search:keyword:page:3:limit:20，value存JSON数组
• 注意缓存穿透：空结果也缓存短时间（如30秒），避免恶意刷不存在的页码打垮DB
• 缓存更新策略：数据变更时，清掉相关分页key（如更新某商品，清掉含该商品的搜索页缓存），而非全量刷新

基本上就这些。优化分页不是堆硬件，而是看清数据访问模式——是线性滚动？还是随机跳转？是读多写少？还是实时性要求极高？选对方法，比调优参数管用十倍。