陆拾贰號1. 深度分页问题的本质与表现
当我们在MySQL中执行类似SELECT * FROM table LIMIT 1000000, 10这样的查询时，就是在制造典型的深度分页场景。数据库引擎必须先读取1000010条记录，然后丢弃前100万条，只返回最后的10条——这种操作的成本与偏移量成正比增长。
我在处理电商平台订单系统时曾遇到一个典型案例：用户查询第500页的订单数据（每页20条）时，页面响应时间从常规的200ms骤增到12秒。通过EXPLAIN分析发现，虽然使用了索引，但MySQL仍需执行"读取-排序-丢弃"的完整流程。这种性能劣化在偏移量超过10万后尤为明显。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 常规分页方案的性能瓶颈
2.1 LIMIT-OFFSET的工作原理
MySQL处理LIMIT offset, size时实际执行的是：
- 通过索引/全表扫描获取
offset+size条完整记录 - 在内存或临时文件中进行排序（如果包含ORDER BY）
- 丢弃前offset条记录
- 返回剩余的size条记录
在500万条用户数据的测试中，不同分页位置的执行时间对比：
| 页码 | 偏移量 | 执行时间(ms) |
|---|---|---|
| 1 | 0 | 32 |
| 100 | 9900 | 45 |
| 1000 | 99900 | 312 |
| 5000 | 499900 | 1487 |
| 10000 | 999900 | 超时(>3000) |
2.2 索引失效的边界条件
即使WHERE条件命中了索引，当偏移量超过一定阈值后，优化器往往会选择全表扫描。这是因为：
- 回表操作的成本超过直接扫描
- 排序缓冲区(sort_buffer_size)不足以容纳中间结果
- 临时表可能从内存转为磁盘存储
3. 高性能分页解决方案
3.1 游标分页法（推荐方案）
基于有序字段的游标分页能彻底规避OFFSET问题：
sql复制-- 第一页（常规查询）
SELECT id, name, create_time
FROM orders
WHERE user_id = 123
ORDER BY create_time DESC, id DESC
LIMIT 20;
-- 后续页（使用上一页最后一条记录的create_time和id作为游标）
SELECT id, name, create_time
FROM orders
WHERE user_id = 123
AND (create_time < '2023-06-15 14:30:00' OR
(create_time = '2023-06-15 14:30:00' AND id < 789))
ORDER BY create_time DESC, id DESC
LIMIT 20;
关键实现细节：
- 必须使用具有唯一性的排序组合（通常主键+时间戳）
- 前端需要保存最后一条记录的游标值
- 支持双向翻页时需要同时保存首尾游标
3.2 延迟关联优化
对于必须使用传统分页的场景，通过子查询先定位ID再关联：
sql复制SELECT t.*
FROM table t
JOIN (
SELECT id
FROM table
WHERE condition
ORDER BY sort_field
LIMIT 1000000, 10
) tmp ON t.id = tmp.id;
这个方案的性能提升来自：
- 子查询只操作索引列，减少数据量
- 主查询通过主键快速定位
- 避免了不必要的列传输
4. 特殊场景的应对策略
4.1 基于主键的范围分页
当数据具有连续主键时，可以采用区间查询：
sql复制SELECT *
FROM products
WHERE id > 1000000
ORDER BY id
LIMIT 10;
注意事项：
- 需要定期执行
OPTIMIZE TABLE消除空洞 - 删除操作会导致主键不连续
- 适合日志类新增为主的场景
4.2 物化视图预计算
对于固定分页需求的报表系统，可以提前计算分页结果：
sql复制CREATE TABLE page_cache (
page_num INT PRIMARY KEY,
data JSON,
expire_time DATETIME
);
-- 定时任务预填充
INSERT INTO page_cache
SELECT
FLOOR(ROW_NUMBER() OVER()/20) AS page_num,
JSON_ARRAYAGG(JSON_OBJECT('id',id,'name',name)) AS data,
NOW() + INTERVAL 1 DAY AS expire_time
FROM large_table
GROUP BY page_num;
5. 实战中的经验教训
-
索引设计陷阱：曾有一个项目在
(category,status)上建立了联合索引，但分页查询按create_time排序，导致全表扫描。正确的做法是建立(category,status,create_time)的覆盖索引。 -
翻页边界问题：当使用游标分页时，如果两页之间发生数据新增/删除，可能导致重复或遗漏。解决方案是在业务低峰期执行分页查询，或引入事务隔离。
-
分布式ID的排序：在使用雪花ID等分布式主键时，直接按ID排序可能不如按创建时间排序高效，因为ID的时间序部分在高位。
-
缓存策略选择：对于热门分页（如前10页），使用Redis缓存完整分页结果；对于深度分页，更适合缓存游标定位的中间结果。