亿级数据分页查询优化方案与实战技巧

1. 亿级数据分页查询的痛点与挑战

第一次处理千万级数据表的分页查询时，我盯着那个执行时间超过30秒的SQL语句陷入了沉思。当数据量突破亿级门槛后，传统的LIMIT offset, size分页方式开始暴露出致命缺陷——每次查询都需要完整扫描前offset条记录，随着页码增加性能呈指数级下降。这就是让无数开发者头疼的"深分页"问题。

在电商订单系统、物联网传感器数据、金融交易记录等场景中，这种性能瓶颈尤为明显。我曾见过一个分页查询第1000页（每页20条）的请求，数据库需要先读取19980条无用记录才能返回目标数据，不仅消耗大量I/O资源，还可能导致整个数据库连接池被占满。

2. 高性能分页方案选型与原理

2.1 基于游标的分页（Cursor-based Pagination）

游标分页通过记录最后一条数据的定位标识（通常是自增ID或时间戳）来实现分页。以下是一个典型实现：

sql复制-- 第一页查询
SELECT * FROM orders 
WHERE user_id = 100 
ORDER BY id DESC 
LIMIT 20;

-- 后续页查询（假设上一页最后一条记录的id是12345）
SELECT * FROM orders 
WHERE user_id = 100 AND id < 12345
ORDER BY id DESC 
LIMIT 20;

优势分析：

• 时间复杂度稳定为O(N)，N为每页条数
• 不受页码深度影响
• 天然支持新增数据时的分页一致性

适用场景：

• 无限滚动加载
• 时间线类数据展示
• 需要保持数据一致性的分页需求

2.2 延迟关联优化（Deferred Join）

对于复杂查询场景，可以先将主键分页后再关联获取完整数据：

sql复制SELECT t1.* FROM orders t1
JOIN (
    SELECT id FROM orders
    WHERE user_id = 100
    ORDER BY create_time DESC
    LIMIT 10000, 20
) t2 ON t1.id = t2.id;

性能对比：
| 方案 | 执行时间(100万数据) | 执行时间(1亿数