1. 问题背景与核心痛点
第一次遇到MySQL处理百万级数据分页时，我盯着那个15秒才返回的查询陷入了沉思。分页查询本是再基础不过的功能，但当偏移量(offset)超过10万时，系统响应速度会呈断崖式下跌。这不是简单的"优化索引"就能解决的问题，而是关系型数据库在处理大数据量分页时的固有缺陷。
问题的本质在于LIMIT offset, size的工作机制。当执行SELECT * FROM table LIMIT 100000, 20时，MySQL会先读取100020条记录，然后丢弃前10万条，只返回最后的20条。这个"读取后丢弃"的过程造成了巨大的资源浪费，特别是当offset值很大时，性能损耗会指数级增长。
2. 常规方案与局限性分析
2.1 传统分页的死亡螺旋
sql复制-- 典型的分页查询
SELECT * FROM products
ORDER BY create_time DESC
LIMIT 100000, 20;
这种写法在数据量小时没有问题，但当数据量达到百万级时：
- 需要扫描100020行数据
- 临时排序消耗大量内存
- 产生大量不必要的磁盘I/O
- 随着页码增加性能线性下降
我曾在一个用户行为日志表上测试，当offset达到50万时，查询耗时超过30秒，CPU利用率飙升至90%。这显然无法满足生产环境要求。
2.2 常见优化方案的短板
很多文章会建议以下"优化方案"，但它们各有局限：
-
索引覆盖：只适合查询字段很少的情况
sql复制SELECT id FROM products ORDER BY create_time DESC LIMIT 100000, 20; -
子查询优化：仅适用于特定场景
sql复制SELECT * FROM products WHERE id >= (SELECT id FROM products ORDER BY id LIMIT 100000, 1) LIMIT 20; -
预先计算总数：无法解决偏移量大的性能问题
这些方法要么适用场景有限，要么无法从根本上解决大偏移量带来的性能问题。
3. 工业级解决方案实战
3.1 游标分页法（推荐方案）
游标分页是我在电商系统中验证过的最有效方案。核心思路是放弃传统的页码分页，改用条件过滤：
sql复制-- 第一页（常规查询）
SELECT * FROM products
WHERE status = 1
ORDER BY create_time DESC, id DESC
LIMIT 20;
-- 后续页（记录上一页最后一条记录的create_time和id）
SELECT * FROM products
WHERE status = 1
AND (create_time < '2023-06-01 12:00:00' OR
(create_time = '2023-06-01 12:00:00' AND id < 12345))
ORDER BY create_time DESC, id DESC
LIMIT 20;
实现要点：
- 排序字段必须创建联合索引（如
(status, create_time, id)） - 必须使用确定性的排序（添加id保证顺序唯一）
- 前端需要保存"上一页最后一条记录"的游标值
在2000万条数据的测试中，无论查看第1页还是第1000页，查询时间都稳定在50ms以内。
3.2 延迟关联优化
对于必须使用传统分页的场景，可以采用延迟关联技巧：
sql复制SELECT t.* FROM products t
INNER JOIN (
SELECT id FROM products
ORDER BY create_time DESC
LIMIT 100000, 20
) tmp ON t.id = tmp.id;
这个方案之所以高效，是因为：
- 子查询只需要扫描索引列(id)
- 通过INNER JOIN快速定位具体记录
- 减少了临时表的数据量
实测在offset=50万时，查询时间从12秒降至0.8秒。
3.3 业务折衷方案
在某些业务场景下，可以牺牲部分精确性换取性能：
- 禁止跳页：只允许"上一页/下一页"操作
- 分片查询：按时间范围先缩小数据集
sql复制SELECT * FROM products WHERE create_time BETWEEN '2023-01-01' AND '2023-06-01' ORDER BY create_time DESC LIMIT 0, 20; - 缓存总数：定期更新总记录数而非实时计算
4. 性能对比与选型建议
4.1 各方案基准测试
在2000万条数据的测试环境中（MySQL 8.0，16核32G内存）：
| 方案 | offset=1万 | offset=10万 | offset=100万 |
|---|---|---|---|
| 传统LIMIT | 120ms | 950ms | 9.2s |
| 子查询优化 | 45ms | 380ms | 3.8s |
| 延迟关联 | 30ms | 250ms | 2.5s |
| 游标分页 | 15ms | 15ms | 15ms |
4.2 选型决策树
根据业务场景选择合适方案：
- 用户端分页（如商品列表）→ 游标分页
- 后台需要跳页的报表 → 延迟关联
- 固定条件的筛选查询 → 分片查询+游标
- 必须显示总页数 → 缓存总数+延迟关联
5. 实施注意事项
5.1 索引设计规范
- 排序字段必须包含在索引中
- 多字段排序时注意索引顺序
sql复制-- 好的索引 ALTER TABLE products ADD INDEX idx_status_ctime_id (status, create_time, id); -- 坏的索引（无法用于排序） ALTER TABLE products ADD INDEX idx_id_ctime (id, create_time); - 区分度高的字段放在索引前面
5.2 常见陷阱
-
排序不一致：没有使用确定性排序导致分页重复
sql复制-- 错误写法（create_time可能重复） ORDER BY create_time DESC -- 正确写法 ORDER BY create_time DESC, id DESC -
字符集问题：utf8mb4字段排序性能比utf8慢约20%
-
隐式类型转换：WHERE条件与索引字段类型不匹配导致索引失效
5.3 监控指标
实施分页优化后需要监控：
- 平均查询响应时间（应<100ms）
- 慢查询日志中的分页语句
- 数据库CPU使用率峰值
6. 高级技巧与边缘案例
6.1 分布式ID分页
在使用雪花ID等分布式ID时，可以利用ID的时间有序性：
sql复制SELECT * FROM orders
WHERE id < 上次最小ID
ORDER BY id DESC
LIMIT 20;
6.2 JSON分页优化
对于JSON字段的分页查询，可以提取排序字段物化：
sql复制ALTER TABLE products ADD COLUMN price_value DECIMAL(10,2)
GENERATED ALWAYS AS (JSON_EXTRACT(price, '$.value')) STORED;
CREATE INDEX idx_price ON products(price_value);
6.3 分页与分区表
当表按时间分区时，可以结合分区裁剪优化：
sql复制SELECT * FROM logs PARTITION(p202306)
WHERE create_time > '2023-06-01'
ORDER BY id DESC
LIMIT 20;
7. 实战问题排查记录
7.1 案例：分页查询突然变慢
现象：原本50ms的查询突然变成2秒
排查过程：
- 检查EXPLAIN发现使用了filesort
- 确认索引未被删除
- 发现数据量从100万激增到500万
- 优化器认为全表扫描比索引更快
解决方案：
sql复制-- 强制使用索引
SELECT * FROM products FORCE INDEX(idx_ctime)
ORDER BY create_time DESC
LIMIT 100000, 20;
7.2 案例：分页结果重复
现象：用户反映看到重复商品
原因：排序字段不唯一，新增数据导致位置变化
修复方案：
sql复制-- 增加ID作为次要排序条件
ORDER BY create_time DESC, id DESC
8. 未来架构思考
当单表数据超过5000万时，即使最优化的分页查询也会遇到瓶颈。这时需要考虑：
- 读写分离：将分页查询路由到只读副本
- 分库分表：按时间或ID范围水平拆分
- 搜索引擎：将数据同步到Elasticsearch等专业搜索工具
- 物化视图：预计算常见分页查询结果
但架构升级前，请先确认是否真的需要精确分页。很多场景下，"无限滚动"或"加载更多"的交互方式可以完全避免传统分页问题。