在后端开发的江湖里处理分页逻辑kan似简单，实则暗藏杀机。每一个初入茅庐的程序员，大概dou写过类似这样的SQL语句：SELECT * FROM orders ORDER BY create_time DESC LIMIT 100000, 10。在数据量还小的时候，这玩意儿跑得比兔子还快，老板满意，用户开心，世界和平。

但是当你的订单表、流水表或者日志表像吹气球一样膨胀到千万级，甚至逼近亿级大关时这句曾经引以为傲的SQL就会变成一颗定时炸弹。你会发现数据库的CPU飙升，磁盘IO打满，Zui后直接把服务干崩。这时候你才意识到，原来“分页”这两个字，在水深火热的互联网大厂里是一道足以决定生死的面试题，geng是实际业务中必须拿下的性Neng高地。

一、 掉坑里了：传统分页的致命伤

咱们先来复盘一下那个Zui经典的“坑”。为什么说LIMIT offset, size在深分页场景下是性Neng杀手？

hen多人直觉上认为，数据库就像一个精明的图书管理员，我告诉他我要第10000页之后的10条，他应该直接跑到那个位置拿给我。但残酷的现实是MySQLgeng像是一个按顺序数数的笨小孩。

当你执行LIMIT 1000000, 10时数据库引擎需要先去扫描索引，找到符合排序条件的前1000010行记录。注意，是“扫描”并“读取”这100万条数据！它必须把这100万条数据dou过一遍，然后无情地把前100万条扔进垃圾桶，只留下Zui后10条给你。这就好比你想吃三明治的第10层火腿，结果厨师非要把上面9层面包dou嚼一遍再吐出来给你，这效率Neng高吗？

随着偏移量的增加，扫描的成本呈线性上升。到了千万级数据量，这种操作简直就是对服务器资源的公开抢劫。不仅查询慢，还会导致大量的Buffer Pool污染，把真正有用的热数据挤出内存。

二、 破局之道：游标分页

既然“数数”太慢，那我们Neng不Neng换个思路？别告诉数据库我要“跳过”多少条，而是直接告诉它“从哪里开始”。这就是我们要说的核心方案——游标分页，也有人叫它“键集分页”或“Seek Method”。

这其实是处理海量数据分页的“Zui优解”，适配了90%的业务场景，特别是APP里的无限下拉翻页。它的核心逻辑非常简单：利用有序的索引字段作为游标。

1. 基础实现：ID作为游标

假设我们有一张订单表，主键是id，并且是自增的。

第一页查询：这和传统写法没区别。

SELECT * FROM orders ORDER BY id DESC LIMIT 10;

假设返回的结果中，Zui后一条记录的ID是9980。

第二页查询：这时候，我们不再计算偏移量，而是直接告诉数据库：“给我找所有ID小于9980的记录，取前10条”。

SELECT * FROM orders WHERE id <9980 ORDER BY id DESC LIMIT 10;

kan到了吗？因为id通常是有索引的，数据库Ke以直接利用B+树结构，瞬间定位到id = 9980的位置，然后向左扫描10个节点就结束了。完全不需要扫描那前100万条数据！这种查询效率是O级别的，无论你翻到第几页，速度dou一样快。

2. 进阶场景：双字段游标

有经验的朋友马上会反驳：“现实业务里我们hen少只按ID排序，大多是按时间排序，而且时间可Neng会重复！”。

确实Ru果只按create_time排序，当同一秒内有大量订单产生时单纯用时间Zuo游标就会出现数据遗漏或重复。这时候，就需要祭出双字段游标的大招了。

通常我们会用这个组合作为排序依据。因为ID是唯一的，它Ke以作为“决胜局”来处理时间相同的情况。

SQL写法如下：

-- 第一页
SELECT * FROM orders ORDER BY create_time DESC, id DESC LIMIT 10;
-- 假设Zui后一行数据是 
-- 下一页查询
SELECT * FROM orders 
WHERE  
   OR 
ORDER BY create_time DESC, id DESC 
LIMIT 10;

这种写法虽然SQLkan起来稍微啰嗦一点，但它Neng完美解决并发插入时的数据一致性问题，是阿里云等大厂在处理海量流水查询时的标准姿势。

三、 折中方案：延迟关联

当然世界上没有绝对完美的方案。游标分页虽然快，但它有一个致命的缺点：不支持随机跳转。用户不Neng直接点“第50页”，只Neng“下一页”、“下一页”地翻。Ru果你的业务场景必须支持传统的页码跳转，那该怎么办？

这时候，我们Ke以采用一种叫“延迟关联”的优化策略。它的核心思想是：先只查ID，再回表查数据。

回顾一下那个慢查询：SELECT * FROM orders ... LIMIT 1000000, 10。它慢的原因在于，它要先扫描100万行，而且这100万行包含了所有字段的数据，IO开销巨大。

Ru果我们只查ID呢？IDdou在索引里不需要回表，速度会快hen多。

SELECT * FROM orders 
INNER JOIN (
    SELECT id FROM orders ORDER BY create_time DESC LIMIT 1000000, 10
) AS tmp USING;

在这个写法中，子查询只扫描了索引，获取到了10个目标ID，然后通过这10个ID去主键索引里把完整数据查出来。虽然还是扫描了100万个索引节点，但避免了100万次的数据行读取，性Neng提升非常明显。这在MySQL的千万级数据分页优化中，是一个非常实用的技巧。

四、 面试官想听什么？

Ru果这是阿里云的社招面试，当你抛出上面的方案后面试官可Neng还会追问：“那Ru果数据量到了亿级，单表扛不住了怎么办？”

这时候，你就得聊聊架构层面的东西了。

当单表数据突破亿级，单纯的SQL优化Yi经杯水车薪。这时候通常会引入分库分表策略。比如按用户ID取模分片，或者按时间范围进行冷热分离。对于历史数据，可Neng直接归档到NoSQL数据库中。

分页查询会变得异常复杂。你不Neng简单地ORDER BY了因为数据散落在不同的物理节点上。通常的Zuo法是：先在各个分片上查出对应的ID，然后在应用层进行归并排序，Zui后只取需要的那一页数据。这也就是所谓的“全局聚合”。

此外针对不同的筛选条件，我们可Neng需要建立二级索引表或者使用Elasticsearch来辅助查询。ES天生支持倒排索引，处理多条件筛选+分页的效率远高于关系型数据库。

五、 与思考

处理千万级数据的分页查询，本质上是一场“空间换时间”或者“逻辑换物理”的博弈。

初级阶段用LIMIT offset，简单粗暴，适合小数据量。

中级阶段意识到性Neng瓶颈，使用覆盖索引优化子查询，或者采用延迟关联减少回表。

高级阶段拥抱游标分页，彻底抛弃offset，利用索引的有序性实现O查询。

架构阶段当单表无解时引入分库分表、异构索引等分布式解决方案。

技术选型从来不是一成不变的。在Zuo决定之前，你得先问问自己：业务真的需要跳转到第500页吗？还是说用户其实只kan前几页？hen多时候，产品经理的一个不合理需求，就会让后端工程师掉进深分页的坑里爬不出来。

所以下次再写分页SQL的时候，多想一步：这表以后会变成千万级吗？Ru果会，现在就别偷懒，把游标分页安排上吧。毕竟深夜被报警

---