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_202401、orders_202402）：分页前先算目标页码落在哪个月份表，再在该表内分页，数据量直接降一个数量级 - 按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（如更新某商品，清掉含该商品的搜索页缓存），而非全量刷新
基本上就这些。优化分页不是堆硬件，而是看清数据访问模式——是线性滚动？还是随机跳转？是读多写少？还是实时性要求极高？选对方法，比调优参数管用十倍。
