sql分页性能优化核心是减少“跳过已排序数据”，需用覆盖索引避免回表、游标分页替代limit offset、延迟关联缩小排序范围，并警惕隐式转换导致索引失效。
SQL排序分页联合查询（如 ORDER BY ... LIMIT offset, size）在大数据量下性能骤降，核心问题在于：MySQL 通常需扫描并排序前 offset + size 行才能返回结果，offset 越大，成本越高。优化不是单纯加索引，而是要减少“无效排序+跳过”行为。
用覆盖索引避免回表排序
如果 ORDER BY 字段和 SELECT 字段都能被同一索引覆盖，MySQL 可直接在索引B+树中完成排序和取值，无需回表读聚簇索引。例如：
原查询：SELECT id, name, created_at FROM orders ORDER BY created_at DESC LIMIT 1000, 20;
优化建索引：ALTER TABLE orders ADD INDEX idx_created_id_name (created_at DESC, id, name);
注意：
- created_at DESC 必须与 ORDER BY 方向一致（8.0+ 支持混合方向，5.7 需统一）；
- 把主键 id 放在第二位，既可用于去重，又支持后续分页定位；
- 若只查 id，索引可简化为 (created_at DESC, id)，更紧凑。
改用游标分页（Cursor-based Pagination）
替代 LIMIT offset, size，用上一页最后一条记录的排序字段值作为下一页起点，彻底消除偏移扫描：
- 第一页：
SELECT id, name, created_at FROM orders ORDER BY created_at DESC LIMIT 20; - 第二页（假设上一页最后一条
created_at = '2024-05-01 10:30:00'）：SELECT id, name, created_at FROM orders WHERE created_at - 要求排序字段必须唯一或组合唯一（否则可能漏/重），推荐搭配主键：
WHERE (created_at, id)
延迟关联减少排序数据量
当排序字段在小表、但需关联大表取详情时，先用索引快速取出ID，再关联补全字段：
原低效写法：SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id ORDER BY o.created_at DESC LIMIT 1000, 20;
优化写法：
SELECT o.*, u.name<br> FROM (SELECT id FROM orders ORDER BY created_at DESC LIMIT 1000, 20) AS tmp<br> JOIN orders o ON o.id = tmp.id<br> JOIN users u ON o.user_id = u.id;
原理：子查询只排序主键 id（轻量），外层再按ID精确回查，避免对所有字段排序。
警惕隐式类型转换与函数导致索引失效
以下写法会让 ORDER BY 无法使用索引：
-
ORDER BY CAST(created_at AS DATE)→ 改为created_at >= '2024-05-01' AND created_at 配合索引 -
ORDER BY UPPER(name)→ 建函数索引（MySQL 8.0+）：CREATE INDEX idx_name_upper ON orders (UPPER(name)); -
WHERE status = 1 ORDER BY create_time但没给(status, create_time)建联合索引 → 查询条件+排序字段应合并索引
分页性能瓶颈本质是“跳过大量已排序数据”，优化方向始终围绕：减少排序范围、避免回表、改用定位而非偏移。游标分页+覆盖索引是最有效的组合策略。
