每一个后端开发人员似乎dou经历过那个令人抓狂的深夜时刻：监控报警红灯闪烁，数据库CPU飙升到100%，而罪魁祸首往往只是一个kan似人畜无害的分页查询。你可Neng会疑惑，明明只是把 LIMIT 0, 10 改成了 LIMIT 100000, 10，为什么整个世界就崩塌了？

这不仅仅是一个技术问题，geng像是一场关于资源与耐心的博弈。今天我们就来扒一扒“深分页”这个老顽固，kankan它到底是怎么把我们的数据库拖进泥潭的，以及我们该如何优雅地把车开出来。

OFFSET 的甜蜜陷阱：你以为的“跳过”，其实是“遍历”

hen多刚入行的朋友潜意识里觉得，数据库在执行 LIMIT 100000, 10 时会像拥有瞬间移动Neng力一样，直接定位到第100,001条记录，然后顺手拿走接下来的10条。Ru果真是这样，那世界就太平了。

残酷的现实是对于大多数数据库来说OFFSET 并不是“跳过”，而是“读取并丢弃”。

想象一下老板让你去档案室找第10001到10010份文件。你并不是直接走到那个柜子前拿走文件，而是必须从第一份文件开始，一份一份地kan，把前10000份dou过一遍，确认它们不是你要找的，扔到地上，然后才Neng拿到那真正需要的10份。这时候，你的体力和脑力Yi经消耗殆尽了而真正的工作才刚刚开始。

这就是为什么随着页码越深，查询速度越慢。因为 OFFSET 值越大，数据库需要扫描、排序、然后丢弃的行数就越多。这种浪费是线性增长的，甚至Ke以说是“雪上加霜”。当数据量达到百万甚至千万级别时这种性Neng瓶颈会变得尤为明显，甚至导致服务直接“雪崩”。

一个简单的实验：眼见为实

为了验证这个说法，我们不妨在脑子里跑一个实验。假设我们有一张表 t_big，结构如下：

CREATE TABLE t_big (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id INT NOT NULL,
  created_at DATETIME NOT NULL,
  payload VARCHAR NOT NULL,
  KEY idx_user_created 
) ENGINE=InnoDB;

这里有个小细节值得注意：索引 idx_user_created 的顺序是 user_idcreated_atid。把过滤列放在前面排序列放在后面通常Neng得到geng高效的执行计划，这算是一个不成文的Zui佳实践吧。

当我们执行如下查询时：

SELECT id, created_at, payload
FROM t_big
WHERE user_id = 1
ORDER BY created_at DESC, id DESC
LIMIT 10 OFFSET 100000;

数据库的执行路径大概率是这样的：先利用索引定位到 user_id = 1 的数据，然后按照 created_at 倒序排列。为了找到偏移量100000之后的数据，它必须先读取前100010条记录的主键ID，然后去回表查询，Zui后把前100000条扔掉。

Ru果 OFFSET 从1万涨到10万，再到100万，你会发现查询耗时呈指数级上升。这期间，大量的CPU时间花在了无用的排序和I/O读取上。属实是费力不讨好。

优化方案一：延迟关联——只回表有用的数据

既然知道了“回表”和“扫描”是性Neng杀手，那我们Neng不Neng先只查索引，把范围缩小，再回表呢？这就是所谓的“延迟关联”或者“子查询优化”。

普通的深分页查询可Neng是这样的：

SELECT id, age, name 
FROM tb_user 
WHERE age> 10 
LIMIT 50000, 100;

在这个查询中，age 是二级索引。数据库需要扫描50100条二级索引记录，然后回表去查50100次聚簇索引，Zui后丢弃前50000行。这简直是资源浪费的教科书案例。

我们Ke以 成这样：

SELECT t1.id, t1.age, t1.name 
FROM tb_user t1 
JOIN (
    SELECT id FROM tb_user WHERE age> 10 LIMIT 50000, 100
) t2 ON t1.id = t2.id;

在这个逻辑里子查询 t2 只在二级索引树上跑，它不需要回表，因为它只需要 id。当它筛选出那100个符合条件的 id 后再通过主键进行100次回表查询。

kan，区别就在这里：回表次数从50100次降到了100次。虽然扫描50100条索引记录的开销还在但至少省下了巨大的I/O成本。对于hen多场景来说这Yi经Neng起到立竿见影的效果。

优化方案二：游标分页——彻底告别 OFFSET

虽然延迟关联Neng缓解回表压力，但它还是没Neng解决“扫描并丢弃”这个核心痛点。Ru果我们想从根本上解决问题，就得换个思路：不要告诉数据库“跳过多少条”，而是告诉数据库“从哪里开始”。

这就是游标分页，也叫 Seek 分页。

它的核心思想非常直接：前端不传 page=50，而是传上一页Zui后一条记录的排序键。比如上一页Zui后一条数据的 created_at 是 2023-10-01 12:00:00，id 是 12345，那么下一页的查询条件就是“比这个时间geng晚，或者时间相同但IDgeng大的数据”。

SQL 写出来大概是这样：

SELECT id, created_at, payload
FROM t_big
WHERE user_id = 1 
  AND (
    created_at <:last_created_at 
    OR 
  )
ORDER BY created_at DESC, id DESC
LIMIT 10;

这种方式让数据库从一个确定的位置继续往下取，完全不需要计算偏移量。无论你翻到第几页，查询性Nengdou是恒定的，O 的复杂度，简直丝滑。

关于排序的稳定性

不过Seek 分页要稳定，还得加上匹配的索引，得和 WHERE + ORDER BY 的字段相匹配。而且，千万不要只用 created_at 这类时间字段排序。数据量一大、同一时间戳hen多时就hen容易出现顺序乱跳的情况。

正确Zuo法是 时间字段 + 唯一键 组成稳定排序。比如上面的例子中，我们用了 ORDER BY created_at DESC, id DESC。这样即使 created_at 相同，也Neng用唯一键 id 把顺序固定下来确保分页不会出现重复或遗漏。

鱼与熊掌不可兼得

当然这世上没有完美的方案。Seek 分页虽然快，但它也有自己的脾气：它geng适合“下一页 / 滚动加载”这种连续翻页的场景。Ru果业务需要支持“直接跳到第500页”，Seek 分页就抓瞎了。因为要跳到第500页，你必须先知道第499页Zui后一条记录是什么这意味着你还是得从头跑一遍。

Ru果业务确实强依赖跳页，一般会用这些方案来 fallback：限制Zui大翻页数，或者还是老老实实回滚到 LIMIT/OFFSET，但配合缓存或异步处理来缓解压力。

生活与技术：别让系统过载，也别让自己过载

聊了这么多技术细节，其实写代码和过日子挺像的。我们总是习惯于透支一点点，觉得多加一个 OFFSET 没什么多熬一个夜也没什么。但就像数据库会因为深分页而崩溃一样，人的身体也是有极限的。

今天又kan到一个程序员加班猝死的新闻，甚至在抢救时、离世后仍然不停有工作消息找过来真是荒诞的现实。说真的，项目Ke以延期，需求Ke以砍，公司离了任何一个人douNeng运转，但命只有一次。

我们在优化代码，追求低延迟、高并发的时候，也别忘了优化自己的生活。深分页慢是因为 offset 越大，浪费扫描、排序、回表、I/O资源越多；人活得累，往往也是因为背负了太多不必要的“offset”，在无效的焦虑和内耗中消耗了精力。

生活总是要负重前行，可一旦感觉有些吃力了一定要早些休息。不要等到系统“雪崩”了才想起来去重启，那时候可Neng就真的来不及了。

如何选择你的方案

Zui后让我们回归技术本身，一下面对深分页时的策略选择：

1. 覆盖索引优化： 原理：利用子查询先在索引树中定位主键，减少回表次数。 优点：改动小，兼容性好，适合既有系统的改造。 缺点：依然需要扫描大量索引行，offset 极大时效果有限。

2. 游标分页： 原理：使用上一页的Zui后一条数据作为游标，直接定位下一页。 优点：性Neng恒定，不受分页深度影响，速度极快。 缺点：不支持随机跳页，需要前端配合传递游标。

3. 业务规避： 原理：限制Zui大页码，或者禁止深分页。 优点：从根源上解决问题。 缺点：用户体验可Neng受损，需要产品经理拍板。

深分页问题通常出现它是偏移量越大、查询效率越低的典型代表。希望这篇文章Neng帮你理清思路，下次遇到查询变慢时Neng知道该往哪里下手。当然geng希望你在优化完SQL之后Neng关上电脑，好好睡个觉。

---