MySQL亿级数据分页优化实战与性能对比

1. 问题背景与核心挑战

在数据量突破亿级大关的业务场景中，传统的分页查询方式往往会遭遇严重的性能瓶颈。我曾参与过一个用户行为分析系统的优化，当数据量达到3.2亿条时，一个简单的LIMIT 1000000, 20查询需要执行超过12秒——这还只是单表查询的最简单情况。

深分页问题的本质在于数据库的工作机制。以MySQL为例，当执行LIMIT offset, size时，数据库需要先读取offset+size条记录，然后丢弃前offset条，只返回最后的size条。这意味着查询LIMIT 1000000, 20实际上需要先读取1,000,020条记录。

2. 常规解决方案的局限性

2.1 传统分页的性能分析

sql复制-- 典型分页查询
SELECT * FROM user_behavior 
ORDER BY create_time DESC 
LIMIT 1000000, 20;

在InnoDB引擎下，这个查询需要：

1. 通过二级索引找到满足条件的记录主键
2. 根据主键回表查询完整数据
3. 对所有结果集进行排序
4. 跳过前1,000,000条记录

当offset值很大时，步骤3和4会成为主要性能瓶颈。在我们的测试环境中，offset超过50万后响应时间呈指数级增长。

2.2 常见优化方案的不足

很多团队会尝试以下优化方法：

• 使用覆盖索引：确实能减少回表操作，但对排序和跳过记录无帮助
• 加大缓存：治标不治本，无法解决首次查询的延迟
• 预计算分页：占用大量存储空间，实时性差

3. 高性能分页方案实战

3.1 游标分页法（Cursor-based Pagination）

这是处理深分页最有效的方法之一。核心思想是记住上一页最后一条记录的位置，而不是使用数值offset。

sql复制-- 第一页（假设每页20条）
SELECT * FROM user_behavior 
ORDER BY create_time DESC, id DESC
LIMIT 20;

-- 后续页（假设上一页最后一条记录的create_time='2023-05-20 15:30:00', id=12345）
SELECT * FROM user_behavior 
WHERE (cre