陆拾贰號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_i