大表分页查询在MySQL中容易出现性能问题，尤其是使用
OFFSET偏移量较大的
LIMIT语句时。随着页码增大，查询会变得越来越慢，因为MySQL需要扫描并跳过前面大量数据。以下是几种实用的优化策略。
1. 使用基于游标的分页（延迟关联）
避免使用
LIMIT 1000000, 10这类高偏移量查询。取而代之的是利用主键或索引列进行范围查询。
例如，假设你要按
id排序分页： -- 普通低效写法
SELECT * FROM large_table ORDER BY id LIMIT 1000000, 10;
-- 优化写法：记住上一页最大id
SELECT * FROM large_table WHERE id > 1000000 ORDER BY id LIMIT 10;
这样可以利用主键索引直接定位，避免全表扫描和跳过大量行。
2. 覆盖索引 + 延迟关联
如果查询字段较多，但排序和过滤字段有索引，可先通过索引获取主键，再回表查数据。
SELECT t.*
FROM large_table t
INNER JOIN (
SELECT id FROM large_table
WHERE status = 1
ORDER BY create_time
LIMIT 1000000, 10
) AS tmp ON t.id = tmp.id;内层查询只走索引（覆盖索引），速度快；外层再根据主键精确回表，减少随机IO。
3. 提前缓存或预计算
对于访问频繁但更新不频繁的数据，可将分页结果缓存到Redis或内存中。
也可以建立汇总表或物化视图，定期更新分页快照。
比如后台报表类需求，每天凌晨生成一次分页索引表，查询时直接读取。
4. 限制分页深度
用户很少翻到几千页之后。可在业务层面限制最大页数，比如只允许翻到第100页。
提示“仅展示最近XXX条数据”，引导用户加筛选条件，减少无效查询。
5. 优化索引设计
确保排序和WHERE条件涉及的字段有合适的复合索引。
例如：
CREATE INDEX idx_status_time ON large_table(status, create_time);
这样
WHERE status=1 ORDER BY create_time就能高效执行。
基本上就这些。核心思路是避免大偏移量的
OFFSET，改用索引定位或缓存机制。结合业务场景选择合适方案，性能提升会非常明显。
