一、什么是深分页
limit 1000000, 10偏移量越大越慢，原理：MySQL 会先扫描前 1000010 行，丢弃前 1000000 行，只返回后 10 行，偏移越大，回表、排序、IO 开销爆炸。
二、最优常用优化方案（按推荐优先级）
- 主键 / 索引书签分页（最常用、性能最强）
原理：不用偏移，用上一页最后一条 ID 做条件
sql
-- 第一页
select * from t order by id limit 10;
-- 第二页：记住上一页最大 id = 100
select * from t where id > 100 order by id limit 10;优点：走索引定位，毫秒级，千万级数据也稳适用：APP / 列表下拉翻页、有自增唯一有序字段
- 延迟关联（先查主键，再关联查详情）
适合必须用 limit offset 场景
sql
-- 慢写法
select * from t order by create_time limit 100000,10;
-- 优化写法：先只查主键，再关联
select t.*
from t
join (select id from t order by create_time limit 100000,10) tmp
on t.id = tmp.id
order by t.create_time;原理：先在覆盖索引上扫少量主键，再回表，减少大量无效数据回表。
- 子查询定位起点
这种方法可以看作是延迟关联的变种，它通过两次查询来避免大的 OFFSET。
原理：第一次查询仅使用覆盖索引，通过 LIMIT offset, 1 获取目标分页位置那条记录的排序字段值。第二次查询则使用这个值作为 WHERE 条件的起点，来获取完整数据。
示例：
sql
-- 1. 先查出第 1000000 行的 create_time (利用覆盖索引)
SELECT create_time FROM t_order ORDER BY create_time LIMIT 1000000, 1;
-- 假设查出的值为 '2026-01-01 12:00:00'
-- 2. 再用该值作为起点查询完整数据
SELECT * FROM t_order
WHERE create_time >= '2026-01-01 12:00:00'
ORDER BY create_time
LIMIT 10;优点：完全避免了 OFFSET，性能稳定。
缺点：需要两次数据库交互；排序字段必须有索引，否则第一步查询依然很慢。
- 覆盖索引优化
排序、分页字段建立联合覆盖索引，避免回表例：按时间分页
sql
create index idx_ct_id on t(create_time, id);查询只查索引里有的字段，直接索引命中，不走数据行。
-
禁止大 offset，业务层限制
业务上不允许用户跳到第 1000 页
超过指定页数（如 100 页）提示：仅支持前 100 页查看
产品层面解决技术难题，成本最低。
-
分区表分页（千万级大表）
按时间范围做分区表（按天 / 按月）分页时自带裁剪分区，只扫描当前分区数据，不用扫全表。
-
业务归档 + 冷热分离
历史冷数据归档到归档表，主表只保留近期热数据，主表数据量小，分页天生快。
-
用 Redis / ES 做分页检索
复杂搜索、排序、深分页直接丢 Elasticsearch
Redis 缓存列表有序集合，做下拉翻页
适合搜索类、海量列表场景。
-
禁用 select *
只查需要字段，减少网络传输、内存开销、提升覆盖索引命中率。
三、避坑关键点
order by 字段必须建索引，否则深分页必慢；
无索引排序会触发 filesort 文件排序，大数据量直接卡死；
limit offset,size offset 超过 1w 就应该优化；
分页一定要有唯一排序键（比如 id），避免排序重复导致数据错乱。
四、一句话选型
能改业务下拉翻页 → 书签分页（id > 上页最大 id）
必须跳页、不能改业务 → 延迟关联 + 覆盖索引
千万级大表 → 分区表 + 冷热归档
复杂检索排序 → ES 替代 MySQL 分页