SQL分页慢的根源是OFFSET需扫描跳过大量数据，优化应采用游标分页、覆盖索引、避免深分页COUNT、归档分表等策略，核心是减少扫描与回表。
SQL分页查询慢，根本原因不是“LIMIT OFFSET”写法本身，而是数据库要先扫描并跳过前面大量无关数据。优化的核心是避免全表或大范围扫描，用更高效的定位方式代替“数数跳行”。
用主键/索引字段替代OFFSET
OFFSET N 实质是让数据库先查出前N+M行，再丢弃前N行——N越大越慢。如果表有自增主键（如id）或唯一且有序的索引字段，可改用“游标分页”（Cursor-based Pagination）：
- 第一页查：SELECT * FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 20
- 第二页查：SELECT * FROM orders WHERE status = 1 AND id
这样每次只走索引范围扫描，不依赖行号计数，性能几乎恒定。
避免深分页时的COUNT(*)全表统计
带总数的分页（如“共123456条，当前第100页”）常在深分页场景下拖垮性能。实际业务中，用户极少翻到几千页，总数往往是误导性信息：
- 前端显示“已加载20条，更多请继续下滑”，不显示总页数
- 用EXPLAIN估算行数（如SHOW TABLE STATUS），或缓存一个近似总数（定时更新）
- 真需要精确总数？只对筛选条件简单、命中索引的查询才实时COUNT，否则直接返回“超过10万+”
覆盖索引减少回表开销
分页查询若涉及SELECT * 或非索引字段，即使排序字段有索引，数据库仍需回表取数据，放大I/O压力。解决方法是让索引“覆盖”所有查询字段：
- 例如：ORDER BY create_time, id，且只查id、title、create_time → 建联合索引 (create_time, id, title)
- 避免在ORDER BY中混用ASC/DESC（MySQL 8.0前不走索引），统一方向
- WHERE条件字段务必纳入索引最左前缀，否则排序索引可能失效
物理分表 or 读写分离辅助分页
单表超千万行后，即使优化索引和写法，单次分页响应仍可能波动。这时需架构层面配合：
- 按时间归档历史数据（如orders_2023、orders_2024），分页集中在热表
- 将分页类查询路由到从库，避免影响主库写入性能
- 高频分页场景（如后台订单列表）可预生成分页快照表，异步更新
基本上就这些。分页不是炫技，而是权衡——多数时候游标分页+合理索引，就能扛住95%的业务场景。别迷信“万能分页组件”，看清数据规模和访问模式，比调参更重要。
