MySQL 5.7深分页慢的根本原因是LIMIT必须扫描并丢弃前offset+size行；真正落地的优化只有两类：一是用主键/有序字段游标分页（如WHERE id > 上一页末id ORDER BY id LIMIT 20），适合滚动加载；二是延迟关联（子查询先取id再JOIN回表），支持跳页但依赖主键索引。
MySQL 5.7 的分页查询一旦 offset 超过几万，响应时间就会明显变长，甚至触发 max_statement_time 超时。这不是配置问题，而是 LIMIT 的执行机制决定的：它必须扫描并丢弃前 offset + size 行。真正能落地的优化，只有两类思路——用游标避开 offset，或用延迟关联绕开全字段扫描。
用主键/有序字段做游标分页（适合滚动加载）
这是 MySQL 5.7 下最稳定、最容易见效的方式，前提是排序字段有索引且值唯一（如自增 id、带索引的 created_at）。
- 第一页查完后，记住返回结果里最后一条的
id值（比如是1056） - 下一页直接写
WHERE id > 1056 ORDER BY id ASC LIMIT 20，不带OFFSET - 必须确保
ORDER BY字段有索引；若含NULL，需在WHERE中显式过滤（5.7 不支持NULLS FIRST） - 不能跳页（比如从第 1 页直接到第 100 页），但对无限滚动、下拉加载等场景完全够用
延迟关联优化大 offset 场景（适合后台管理）
当业务强制要求支持任意页码（如“跳转到第 892 页”），且无法改用游标时，延迟关联是最实用的兜底方案。
- 原始低效语句：
SELECT * FROM users ORDER BY id LIMIT 100000, 20，会扫描 100020 行再丢弃前 10 万 - 优化写法：
SELECT u.* FROM users u INNER JOIN (SELECT id FROM users ORDER BY id LIMIT 100000, 20) t ON u.id = t.id - 原理：子查询只走主键索引（轻量），外层用主键精准回表，避免大量无效字段读取
- 注意：子查询中的
ORDER BY必须和外层一致；若表无主键，该方法失效
别踩这些坑（5.7 特有雷区）
MySQL 5.7 对索引利用更敏感，几个常见错误会让优化完全失效：
-
ORDER BY字段没索引 → 触发Using filesort，性能断崖下跌 - 复合排序（如
ORDER BY status, created_at）却只建了单列索引 → 索引无法覆盖，照样慢 - 用
COUNT(*)查总页数 → 百万级表全表扫一次，比查数据还耗时；建议缓存总数或改用“加载更多” - 在
WHERE条件中用了函数（如WHERE DATE(created_at) = '2025-01-01'）→ 索引失效，游标和延迟关联都救不了
没有自增主键怎么办（fs_id 无序时）
如果主键是类似 fs_id 这种 UUID 或无序值，游标分页会乱序，但仍有解法：
- 先加
ORDER BY fs_id强制排序（哪怕fs_id本身无序，排序后也能形成确定序列） - 首次查询用
WHERE fs_id > '' ORDER BY fs_id LIMIT 20，拿到第一页最后的fs_id - 后续页用
WHERE fs_id > '上一页最后值' ORDER BY fs_id LIMIT 20 - 缺点是排序本身有开销，但比
LIMIT 100000, 20稳定得多；实测 30 万条数据每页耗时波动控制在 ±0.2 秒内
游标分页依赖数据顺序稳定，延迟关联依赖主键索引高效；两者都不解决“跳页+无序主键+高频 COUNT”这种三难组合。真遇到这种场景，得回到业务层——要么加搜索筛选缩小数据集，要么接受用缓存扛住热点页。
