网站如何分块传输数据？大数据库下分页加载的高效实现问询

传统的LIMIT OFFSET分页在大数据场景下效率极低，原因正如你所说：数据库需要先扫描并过滤掉前面的所有偏移量数据，再返回目标结果，数据量越大、偏移量越高，算力消耗就越夸张。大厂的分页/滚动加载机制，核心都是绕开OFFSET的低效逻辑，用以下几种方案实现：

1. 游标（Cursor）分页（信息流场景首选） #

这是Twitter、Instagram这类实时信息流产品的标准方案，核心是用上一页最后一条记录的唯一标识作为“游标”，直接定位下一页的查询起点，完全跳过偏移量扫描。

举个实际例子：假设你有一个posts表，存储用户推文，核心字段是id（自增主键）、content（内容）、created_at（发布时间），我们要按发布时间倒序加载信息流：

• 第一次加载（第一页）：

SELECT id, content, created_at 
FROM posts 
ORDER BY created_at DESC, id DESC 
LIMIT 30;

这里同时按created_at和id排序，是为了避免同一时间发布的推文出现排序混乱或重复。

• 加载下一页时，取上一页最后一条记录的created_at（比如'2024-05-20 12:00:00'）和id（比如1000），用它们作为查询条件：

SELECT id, content, created_at 
FROM posts 
WHERE created_at < '2024-05-20 12:00:00' 
   OR (created_at = '2024-05-20 12:00:00' AND id < 1000)
ORDER BY created_at DESC, id DESC 
LIMIT 30;

这种方案的优势：

• 利用(created_at, id)的联合索引，数据库可以直接定位到游标位置，无需扫描前面的所有数据，查询效率稳定，哪怕是第100页也和第1页一样快。
• 天然适配滚动加载的交互逻辑，前端只需要保存上一页的游标信息即可。

2. 键集分页（Keyset Pagination） #

和游标分页本质是同一逻辑，只是更强调用有序且唯一的键来定位。如果你的排序字段本身是唯一的（比如自增ID、UUID），可以简化查询：

比如按id倒序分页：

• 第一页：

SELECT id, content, created_at 
FROM posts 
ORDER BY id DESC 
LIMIT 30;

• 下一页（假设最后一条ID是1000）：

SELECT id, content, created_at 
FROM posts 
WHERE id < 1000 
ORDER BY id DESC 
LIMIT 30;

这种方案更简单，但前提是排序字段必须唯一，否则会出现数据漏查或重复。

3. 预计算与缓存（搜索/热门内容场景） #

像谷歌搜索这类产品，会提前对热门查询的分页结果进行预计算，把结果分成多个块缓存起来。用户请求时直接读取缓存块，完全绕过数据库查询，极大降低算力消耗。

社交媒体的热门信息流也可以用类似逻辑：比如异步计算用户的首页信息流，按30条为一组缓存，用户滚动时直接读取缓存的下一组，只有当缓存失效或用户刷新时才重新查询数据库。

4. 分段存储（时间维度数据） #

对于按时间排序的内容（比如推文、新闻），可以按时间分片存储：比如按天分成posts_20240520、posts_20240519等分区表或独立表。

查询时先根据用户要加载的时间范围，确定需要访问哪些分片，只查询对应的分片数据，不用扫描全表。比如用户加载最新的信息流，只需要查询当天的分片，数据量小，查询速度自然快。

关键注意点 #

• 所有排序字段必须建立索引：不管用哪种方案，没有索引的排序都会导致全表扫描，效率直接崩盘。
• 深分页禁用OFFSET：如果业务必须支持跳转到第N页（比如电商商品列表），可以结合游标和预计算，或者限制最大跳转页数。
• 处理实时数据插入：用游标分页时，新插入的数据会出现在后续的查询结果中，这是正常的（比如Twitter的“新推文”提示），如果需要避免，可以在查询时加上时间范围限制。

内容的提问来源于stack exchange，提问作者Misa