想象你是一位图书馆管理员，书架上的书按编号整齐排列。读者要借第 10000 本之后的 10 本书，你本可以记住上次借到哪一本、直接从那后面继续取。可 LIMIT 的默认做法却是：每次从第一本书开始数，数过 9999 本再往后拿 10 本。页码越深，你重复数过的书就越多，读者等得越久。这篇文章要讲的，就是如何用“记住位置的书签”代替“从头数起”——对应到数据库世界，就是延迟关联与 keyset 游标分页两种优化思路。读完你会明白，为什么某些分页接口越翻越慢，以及怎样用一条改写过的 SQL 彻底告别这种失控感。

岗位关联

分页是后端接口的日常，优化它不需要奇技淫巧，只需理解扫描代价。这本书式思维会让你面对千万级表单时不再心虚，是进阶排查性能问题的必备底牌。

目录
  1. 可视化演示
  2. 分页原理与代价
  3. 延迟关联优化
  4. 游标分页思路
  5. 场景适用对比
  6. 实践落地要点
  7. 疑难排查方向
  8. 演进与兜底
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

分页原理与代价

读者要看第 200 页的书，图书馆管理员有两种选择：一是从门口第一本书重新数起，数完 1990 本后再拿 10 本；二是记得上次借到哪一本，直接从那里继续。可惜多数分页 SQL 采用了第一种笨办法。LIMIT 1990, 10 的含义是“跳过前面 1990 行，再取 10 行”，数据库被迫逐行读过 1990 条记录后才会真正返回结果。

这个行为对性能的影响是深远的。在数据量小的表格上，跳过几百行几乎无感；可当业务增长到千万行、用户翻到第 10 万页时，数据库每次都要额外扫描 100 万行。响应时间从毫秒级膨胀到秒级甚至分钟级，这就是“深度分页问题”——问题不在取数，而在“跳过”本身。

回到图书馆的比喻：每次从门口数起的管理员，和记住书签位置的管理员，工作量的差距正是 offset 带来的“无效行走”。理解了这个代价公式，你就拿到了优化分页的第一把钥匙——让扫描行数不再随页码膨胀。

T≈offset+limitT \approx \text{offset} + \text{limit}
一次分页查询的总扫描行数约等于偏移量加上每页行数，页号越大，“跳过”的代价越惊人。
  1. 扫描行数构成数据库执行 LIMIT offset, limit 时，必须先越过 offset 行，再读取 limit 行，总工作量等于两者之和。
    T≈offset+limitT \approx \text{offset} + \text{limit}
  2. offset 随页码放大offset 由公式 offset = (页号 - 1) × limit 算出，页码每加一档，跳过量线性上涨。
    offset=(p−1)×limit\text{offset} = (p - 1) \times \text{limit}
  3. 代价不对称limit 固定不变，变的是 offset。页号越大，数据库中真正被“搬运”却最终丢弃的行越多。
    lim⁡p→∞T=∞\lim_{p \to \infty} T = \infty

延迟关联优化

既然直接数过去太费劲，管理员换了个策略：他不再一趟趟跑书架，而是先在目录大厅翻卡片。卡片上记着每本书的编号和位置，翻卡片可比在书架间穿梭快得多。翻到需要的卡片后，他只去对应位置精准取出那 10 本书。这就是“延迟关联”的朴素原理——先用最轻量的方式确定目标身份，再去取完整数据。

技术实现上，延迟关联把一步查询拆成两步。第一步，利用覆盖索引查出本页需要的全部主键 ID。覆盖索引意味着查询所需字段都在索引里，不需要回表，速度极快。第二步，用这些主键 ID 去原表关联查询整行数据，这时才发生真正的“回表”。

注意，延迟关联只是把“逐行翻阅”换成了“快速定位”，但仍然需要计算 offset。它不能消灭翻页成本，却能大幅压缩回表开销。图书馆里，管理员依然要从头数卡片，但翻卡片比搬书快得多，整体体验已经是质变。这一步改写通常三分钟完成，却是高代价 SQL 的经典救星。

Ttotal=Tindex+Trow×limitT_{\text{total}} = T_{\text{index}} + T_{\text{row}} \times \text{limit}
一次延迟关联查询的总代价，是“索引扫描成本”加上“每行回表成本 × 每页行数”。回表次数被牢牢限制在 limit 内，与 offset 再无关系。
  1. 索引定位成本第一步用 SELECT id FROM t ORDER BY … LIMIT offset, limit，InnoDB 在索引 B+ 树上完成定位，这部分的代价记为 T_index。
    Tindex≈O(offset+limit)  但极小T_{\text{index}} \approx O(\text{offset} + \text{limit})\;\text{但极小}
  2. 回表次数固定第二步通过主键 WHERE id IN (…) 回原表取行，回表次数等于 limit，而不再等于 offset。
    回表次数=limit\text{回表次数} = \text{limit}
  3. 总代价收敛当 offset 远大于 limit 时，第二步的固定小额回表让整体耗时趋于稳定。
    Ttotal≈Trow×limit(offset≫limit)T_{\text{total}} \approx T_{\text{row}} \times \text{limit}\quad(\text{offset} \gg \text{limit})

游标分页思路

有没有办法让管理员连卡片都不从头数？有——给他一个书签，上面写着“上一批最后一本书的编号是 10240”。下次读者要下一页，管理员直接走到编号 10240 的书旁，从下 一本开始取。这就是 keyset 分页（游标分页）：用一个有序列记住上一次的位置，用大小比较代替偏移量。

核心 SQL 形态是把 LIMIT offset, limit 改成 WHERE sort_key > last_key ORDER BY sort_key LIMIT limit。注意，这里的比较符号要跟排序方向一致：升序用 >，降序用 <。由于索引天然支持有序查找，数据库可以直接跳到 last_key 之后的位置，完全跳过中间的 offset 行。

书签策略的代价是：用户不能“跳到第 5000 页”。但在“下拉加载更多”“按时间滚动”这类主流交互中，根本不需要跳页。keyset 分页正是为这些场景而生，它在大数据量下拥有绝对的稳定性，也因此成为订单流水、日志查询等场景的首选方案。

WHERE  sort_key>last_key    ORDER BY  sort_key    LIMIT  n\text{WHERE}\;\text{sort\_key} > \text{last\_key}\;\; \text{ORDER BY}\;\text{sort\_key}\;\; \text{LIMIT}\;\text{n}
keyset 分页用“上次位置”做条件过滤，从索引层面跳过中间行，每次查询的扫描量恒定等于 n，不再随页码增长。
  1. 定位起点sort_key > last_key 让 B+ 树从 last_key 的后继位置开始扫描，中间行天然被忽略。
    查找起点=succ(last_key)\text{查找起点} = \text{succ}(\text{last\_key})
  2. 顺序遍历ORDER BY sort_key 保证返回顺序稳定，下一页接在上一页末尾，不重不漏。
    第 k 页∩第 k+1 页=∅\text{第 }k\text{ 页} \cap \text{第 }k+1\text{ 页} = \varnothing
  3. 常量扫描LIMIT n 限定扫描行数，无论数据表多大、翻多少页，工作量始终是 n。
    Tkeyset≈O(n)    (与页码无关)T_{\text{keyset}} \approx O(n) \;\; (\text{与页码无关})

场景适用对比

管理员面对不同读者需求，会灵活切换策略。如果图书馆只有几百本书，从头数起毫无压力；如果书架延伸到仓库深处，书签就是必需品。分页优化同样如此——没有银弹，只有匹配场景后的恰当选择。

先把两种方案的复杂度摆在一起：offset 分页的扫描行数随页码线性增长，keyset 分页恒定。但 keyset 有前提：排序字段必须有索引、必须能记住上次位置、无法直接跳页。在几十万行以内的小表上，offset 的线性增长根本不构成威胁，强行改造反而增加复杂度；在千万行大表且翻页极深时，keyset 的优势则是碾压性的。

所以当你面对“要不要优化分页”的提问时，先问两句：表有多大？用户要翻多深？小表小页码，保持简单；大表深翻页，果断引入 keyset。把策略建立在数据量级和产品交互上，而不是盲目追逐“最先进的写法”。

R=Toffset(p)Tkeyset(p)≈p×limitlimit=pR = \frac{T_{\text{offset}}(p)}{T_{\text{keyset}}(p)} \approx \frac{p \times \text{limit}}{\text{limit}} = p
两种方案的耗时比值约等于页码 p。翻到第 1000 页时，offset 方案的扫描量已是 keyset 的 1000 倍。
  1. 比值定义在相同 limit 下，offset 方案的扫描量约等于 p×limit，keyset 恒为 limit，两者相除得到比值 R。
    R=p×limitlimit=pR = \frac{p \times \text{limit}}{\text{limit}} = p
  2. 临界点当 R 大到你无法接受时（经验上页码超过 100～1000），就该换思路了。
    p临界≈100∼1000p_{\text{临界}} \approx 100 \sim 1000
  3. 产品形态决定策略页码导航用 offset，无限滚动和加载更多用 keyset，这个映射关系在业界高度一致。
    分页控件形态⇒分页策略\text{分页控件形态} \Rightarrow \text{分页策略}

实践落地要点

书签若想可靠，编号必须独一无二。如果书架上两本书贴着同一个编号，管理员按编号定位时就会犹豫：到底该取哪一本？keyset 分页同样要求排序字段唯一。实践中常用主键 id 或“创建时间 + id”组合键，确保永远没有歧义。

另一个要点是索引必须匹配查询。WHERE sort_key > last_key ORDER BY sort_key 需要对应单列索引或复合索引，否则排序和过滤各走各的路，索引失效。同时要留意 NULL 值：> 比较会漏掉 sort_key 为 NULL 的行，必须在表设计时给排序字段加 NOT NULL 约束或默认值。最后，时刻用 EXPLAIN 观察优化器是否真的选择了你期望的索引。

落地 keyset 分页时，最典型的一步是把“时间戳”改成“时间戳 + id”的复合排序，并给这对列建联合索引。这些细节看起来繁琐，却直接决定了书签能不能一插一个准、翻页能不能稳定不丢数据。索引世界里的严谨，换来的正是业务世界里的确定性。

复合索引条件: (a,b)⇒WHERE a=const AND b>last_key\text{复合索引条件: } (a, b) \Rightarrow \text{WHERE } a = \text{const AND } b > \text{last\_key}
复合索引 (a, b) 只有在 a 使用等值、b 使用范围时才能被完整利用，这决定了 keyset 能否真正命中索引。
  1. 最左前缀复合索引 (a, b) 要求查询先给 a 一个固定值，再对 b 做范围比较，才能走完整个索引。
    index(a,b),    a=c,    b>k⇒索引完全覆盖\text{index}(a, b),\;\; a = c,\;\; b > k \Rightarrow \text{索引完全覆盖}
  2. 唯一性保证排序列若重复，> last_key 会跳过与 last_key 相等的行，造成数据遗漏；用主键补齐唯一性。
    sort_key 不唯一⇒加 id 兜底: (sort_key,id)\text{sort\_key 不唯一} \Rightarrow \text{加 id 兜底: } (\text{sort\_key}, \text{id})
  3. NULL 处理SQL 中 NULL 不参与大小比较，排序列为 NULL 时 keyset 永远取不到它，需提前规避。
    NULL∉{x∣x>k}\text{NULL} \notin \{x \mid x > k\}

疑难排查方向

深分页的问题常常不是突然爆发的，而是“温水煮青蛙”。某天接口监控亮起红灯，管理员发现读者在书架间来回走了三个小时——也就是执行计划里的扫描行数暴涨。排查时最先看的就是响应时间曲线：如果延迟随页码平滑上升，十有八九是 offset 深度分页；如果出现断崖式跳变，则要怀疑索引失效或数据分布突变。

其次是 EXPLAIN 里的关键信号：rows 字段显示扫描行数远大于真实返回行数，或者出现 Using filesort。前者说明 offset 正在空转，后者说明排序没有吃到索引。还有一类隐蔽问题：页与页之间数据重复或遗漏。这通常不是因为分页算法本身，而是排序字段不唯一，导致同一行在不同页的排序位置漂移。

把排查当成图书馆的定期盘点：对照监控曲线、执行计划、数据抽样三个数据源交叉验证，通常十分钟内就能锁定问题根因。排查的意义不仅在于修好眼前的分页，更在于把“分页深度”纳入监控体系，让下一次问题提前显形，而不是等业务方来投诉。

offset>limit×103⇒优先排查深度分页\text{offset} > \text{limit} \times 10^3 \Rightarrow \text{优先排查深度分页}
当偏移量超过每页行数的一千倍时，性能几乎必然劣化。这个阈值可以作为监控告警的分页健康线。
  1. 建立告警基线用 offset / limit 定义“分页深度指数”，指数超过阈值即触发告警。
    d=offsetlimit,d>1000⇒告警d = \frac{\text{offset}}{\text{limit}},\quad d > 1000 \Rightarrow \text{告警}
  2. 核对执行计划EXPLAIN 中 rows 应与 limit 同数量级，否则表明有无效扫描。
    rowsexplain≈limit⇒正常;rowsexplain≫limit⇒问题\text{rows}_{\text{explain}} \approx \text{limit} \Rightarrow \text{正常};\quad \text{rows}_{\text{explain}} \gg \text{limit} \Rightarrow \text{问题}
  3. 排序稳定性检查数据重复或遗漏时，验证排序键是否全局唯一。
    重复/遗漏⇒唯一性约束缺失?\text{重复/遗漏} \Rightarrow \text{唯一性约束缺失?}

演进与兜底

图书馆管理方式在演进：从人工数书到书架编号，再到电子目录与书签联动。分页优化也有清晰的演进路径——先确保数据端扫描有索引兜底，再为前端交互选择合适的分页形态，最后配一套监控来发现慢查询。三步走完，分页性能就不再是“碰运气”。

兜底方案要同时考虑前后端。前端把“页码跳转”逐步替换为“加载更多”或“无限滚动”，从交互层面消灭深分页；后端对必须保留页码的场景使用延迟关联，对大数据量场景引入 keyset，并对无法改造的旧接口设置超时与熔断。架构取舍的本质是：用产品体验的微小让步，换取数据库扫描量级的稳定可控。

回看这个分页优化的完整旅程：从认识 offset 的线性代价，到用延迟关联压缩回表，再到用 keyset 彻底摆脱偏移量，最后落到监控与兜底——每一步都在减少“无效行走”。图书馆管理员最终不再从头数书，靠的不是蛮力，而是对书籍组织方式的理解。SQL 优化同样如此：真正的高手，是让数据库在最少的步骤里拿到想要的行。

Tlookup=O(log⁡N)≪O(offset)T_{\text{lookup}} = O(\log N) \ll O(\text{offset})
B+ 树索引定位的复杂度是对数级，而顺序跳过 offset 行是线性级。把分页建立在索引定位之上，是长远最优解。
  1. 索引定位优势每次 keyset 查询通过 B+ 树在 log N 步内找到书签位置，与表大小弱相关。
    Tlookup=log⁡BNT_{\text{lookup}} = \log_B N
  2. 线性扫描劣势offset 方案实际付出的 O(offset) 代价与要丢弃的行数成正比。
    Tskip=O(offset)T_{\text{skip}} = O(\text{offset})
  3. 策略演进方向所有分页优化最终都在把线性扫描替换为对数或常数代价的索引定位。
    演进方向:    O(offset)→O(log⁡N)→O(limit)\text{演进方向}:\;\; O(\text{offset}) \to O(\log N) \to O(\text{limit})

AI 应用场景

大数据报表系统的分页加速

阶段：数据服务与后端查询优化

解决的问题：BI 报表中的明细查询动辄数百万行，业务方习惯用页码跳转，传统 LIMIT 200000, 100 的查询在 MySQL 上耗时数秒，拖垮报表整体体验。AI 平台的数据服务层每天承接大量此类查询，扫描浪费会直接拉高数据库 CPU 与 IO。

具体案例：某数据中台团队的看板页“订单明细”支持页码跳转，第 5000 页后响应超 10 秒。工程师用延迟关联改写：先查覆盖索引 SELECT id FROM orders ORDER BY id LIMIT 500000, 100，再 WHERE id IN (…) 回表，响应降至 300ms 以内，数据库扫描行数下降 99%。

监控告警时间线的游标流式加载

阶段：实时监控与日志检索

解决的问题：监控系统里告警事件按时间倒序排列，用户持续下拉“加载更早的告警”。传统 offset 分页在事件量达到亿级后翻页越来越慢，且用户并不需要跳页，只需要“下一屏”。keyset 分页按时间戳定位，天然匹配这种流式消费场景。

具体案例：云平台告警中心按 occurred_at DESC 展示，游标条件写成 WHERE occurred_at < last_time ORDER BY occurred_at DESC, id DESC LIMIT 50，并建立 (occurred_at, id) 复合索引。改造后任何深度的翻页都稳定在 80ms 内，告警时间线不再卡顿。

电商订单列表的组合分页策略

阶段：业务接口与数据库稳定性治理

解决的问题：电商后台订单查询既要支持页码跳转，又要支持“加载更多”；订单量过亿后单一策略难以两全。AI 驱动的智慧运营系统还会频繁拉取历史订单做特征分析，分页慢会阻塞离线任务。

具体案例：某电商团队按页码深浅分流：游客浏览前 100 页用延迟关联，商家后台“加载更多”用 WHERE id > last_id 的 keyset，分析任务用游标全表扫。三套策略统一封装在 DAO 层，业务方无感切换，数据库 P99 延迟下降 85%。

Python 演示

python43 行
"""Compare OFFSET pagination with keyset pagination on scan cost."""import random  def offset_page(rows, page, page_size):    start = (page - 1) * page_size    visited = min(start, len(rows))    result = rows[start:start + page_size]    return result, visited + len(result)  def keyset_page(rows, page_size, last_key):    visited = 0    result = []    for key in rows:        visited += 1        if last_key is not None and key <= last_key:            continue        result.append(key)        if len(result) >= page_size:            break    return result, visited  def main():    total = 100000    page_size = 10    page = 8000    rows = list(range(1, total + 1))    random.shuffle(rows)    sorted_rows = sorted(rows)     res1, scanned1 = offset_page(sorted_rows, page, page_size)    last_key = sorted_rows[(page - 1) * page_size - 1]    res2, scanned2 = keyset_page(sorted_rows, page_size, last_key)     print("OFFSET page", page, "scanned", scanned1, "rows, got", len(res1))    print("KEYSET page", page, "scanned", scanned2, "rows, got", len(res2))    print("speedup:", round(scanned1 / scanned2, 1), "x faster")  if __name__ == "__main__":    main()
目的：用 10 万行数据模拟“翻到第 8000 页”的场景，直观对比 offset 分页与 keyset 分页各自需要“访问”多少行数据。
  1. start = (page - 1) * page_size计算 offset 语义：跳过第 1 页到第 page-1 页的全部行。
  2. visited = min(start, len(rows))统计 offset 分页为了跳过中间 79990 行所付出的访问量。
  3. result = rows[start:start + page_size]真实返回的只有 10 行，但后台已经遍历了海量数据。
  4. def keyset_page(rows, page_size, last_key)keyset 版从 last_key 之后开始扫描，不需要跳到指定行号。
  5. if last_key is not None and key <= last_key: continue跳过书签之前的所有行，这是“条件替代偏移”的核心。
  6. if len(result) >= page_size: break一旦攒够 10 行立即停止，访问量永远不超过 page_size。
  7. print("speedup:", ...)输出加速倍数，deep page 下通常是几千倍。

常见误区

误区“数据量大是硬件问题，`LIMIT 1000000, 10` 只是让数据库多扫描一百万行，加个高性能 SSD 就能解决。”

正解多扫描一百万行不是“慢一点”，而是把查询从毫秒级推到秒级甚至分钟级。优化器必须真实读取并丢弃这些行，IO、内存、CPU 全部被白耗。这就像让管理员从门口数一百万本书再取 10 本，换双跑鞋解决不了本质问题——应该换思路，直接定位到目标位置。

为何常见：本地小数据量测试时 offset 很小，感受不到差异，容易把深度分页的问题归因于“机器不够好”。

误区“我按排序列建了索引，分页怎么会慢？肯定是 MySQL 版本问题。”

正解单独给 order by 字段建索引，不等于索引被这个查询用上。LIMIT offset, limit 的 offset 机制意味着数据库依然要把前 offset 条索引记录全部走一遍；如果 where 条件与 order by 不使用同一个复合索引，还会触发 filesort。索引要匹配“过滤 + 排序”的完整需求，而不只是排序列本身。

为何常见：人们容易把“索引”当成万能药，忽略了执行计划里索引实际生效的前提条件。

误区“游标分页没法跳到第 5000 页，业务需求不允许，还是老老实实用 offset。”

正解跳页是低频操作，深翻页才是高频痛点。面对海量数据，产品完全可以保留“首页 + 上一页 + 下一页”模式，跳页功能用延迟关联单独实现；多数“加载更多”场景根本不需要页码。为了一个百分之一的跳页需求，让百分之九十九的查询都变慢，是不划算的取舍。

为何常见：开发习惯被传统页码导航框住，忽略了对交互场景的重新审视。

误区“延迟关联先查索引再回表，相当于两次查询，肯定比一次 `SELECT *` 慢。”

正解恰恰相反。传统写法的回表次数约等于 offset + limit，延迟关联把回表次数压缩到 limit。回表是随机 IO，代价极高；索引扫描是有序 IO，代价极低。把大量随机 IO 换成少量随机 IO 加一次顺序索引扫描，是质变而非量变。

为何常见：凭直觉数“查询次数”，忽略了不同类型 IO 之间的巨大成本差异。

面试题

Q1. 执行 SELECT * FROM t ORDER BY id LIMIT 100000, 10 时，数据库大约需要扫描多少行？

单选题 · easy

  • A.只需要读取最后 10 行
  • B.约十万零一十行左右← 正确答案
  • C.只扫描 id 索引十行
  • D.扫描整个表全部行

答案：B。OFFSET 100000 意味着先跳过 10 万行，再取 10 行，总扫描约 100010 行。这就像管理员从第一个书架数到第 10 万本，才发现要借的是后面的 10 本。A、C 忽略 offset 的跳过成本，D 又夸大了范围——表更大时也不会全表扫，但 10 万行的无效遍历已经足够让查询变慢。

Q2. 延迟关联优化中，第一步先做什么？

单选题 · easy

  • A.直接回表获取全部数据
  • B.用覆盖索引查出主键← 正确答案
  • C.给表加上全文索引
  • D.把 limit 改成更大的值

答案：B。延迟关联的第一步是“先翻目录卡片”，用覆盖索引快速查出本页的主键 ID，第二步才回原表取整行。先回表（A）正是传统写法的痛点；加全文索引（C）与排序分页无关；调大 limit（D）只会让问题更严重。核心思路是让最耗时的回表次数收敛到 limit。

Q3. 游标分页（keyset）相比 offset 分页的核心区别是什么？

单选题 · easy

  • A.不再依赖任何排序字段
  • B.用 where 条件代替偏移量← 正确答案
  • C.每页返回的行数无限大
  • D.只适用于单表查询

答案：B。keyset 的核心是 WHERE sort_key > last_key，用有序列上的比较条件直接跳到上次位置，替代“跳过 N 行”。它恰恰依赖排序字段（A 错），返回行数仍由 limit 控制（C 错），也完全可以用于多表关联（D 错）。书签定位替代从头数数，这就是本质变化。

Q4. 覆盖索引生效时，延迟关联需要回表多少次？

单选题 · mid

  • A.等于 offset 大小
  • B.等于 limit 大小← 正确答案
  • C.等于全表行数
  • D.一次都不需要回表

答案：B。第一步用覆盖索引查出主键，本身不需要回表；第二步用主键 IN 查询去原表取整行，回表次数等于 limit。A 是传统写法的代价，C 是把回表和全表扫混为一谈，D 忽略第二部取整行数据的需求。把回表从“offset 级”降到“limit 级”，正是延迟关联快的原因。

Q5. keyset 分页对排序字段有哪些硬性要求？

多选题 · mid

  • A.字段值需要全局唯一← 正确答案
  • B.字段具有稳定顺序← 正确答案
  • C.字段允许大量 NULL
  • D.存在匹配的索引← 正确答案

答案：ABD。排序字段必须是稳定、唯一且有索引的：唯一性保证 > 定位不重不漏（A 对），稳定顺序让翻页方向一致（B 对），索引用作快速定位（D 对）。大量 NULL 会导致字段无法参与大小比较而漏数据（C 错）。就像书签必须有唯一编号，否则管理员无从定位。

Q6. 某报表页深翻到第 8000 页后响应极慢，最合理的优化手段是什么？

单选题 · mid

  • A.调大 MySQL 的缓冲池
  • B.改用延迟关联或 keyset← 正确答案
  • C.把 limit 减小一半
  • D.去掉 order by 子句

答案：B。8000 页的 offset 已高达 8 万行量级，问题根源是“跳过行数太多”，延迟关联和 keyset 都能直接削减扫描量。缓冲池（A）只缓解内存压力不解决扫描逻辑；减小 limit（C）治标不治本；去掉 order by（D）会破坏分页语义。深翻页场景必须从访问路径入手。

Q7. 哪些情况会让延迟关联优化失效？

多选题 · mid

  • A.order by 字段不在索引中← 正确答案
  • B.where 字段未建立索引← 正确答案
  • C.表使用的是 InnoDB 引擎
  • D.查询列超出索引覆盖范围← 正确答案

答案：ABD。第一步要求“排序 + 过滤”都能在索引内完成，order by 字段不在索引（A）或 where 无索引（B）都会让第一步退化；查询列超出索引覆盖范围（D）会导致第一步必须回表，失去延迟关联的意义。InnoDB（C）是 MySQL 默认引擎，恰恰支持这种优化，不会导致失效。

Q8. keyset 分页在“跳页”场景下的主要局限是什么？

单选题 · hard

  • A.无法快速跳到随机页码← 正确答案
  • B.查询结果完全不稳定
  • C.索引会彻底失效
  • D.每次只能返回一条记录

答案：A。keyset 依赖“上一页的末尾位置”作为游标，天然是顺序式的，想跳到第 5000 页需要一个事先算好的 last_key，传统页码导航无法直接支持。它的结果在顺序翻页时是稳定的（B 错），索引设计正确就不会失效（C 错），返回行数由 limit 控制（D 错）。所以 loading more 场景才是它的主场。

Q9. 哪些信号表明当前分页存在深度分页问题？

多选题 · hard

  • A.扫描行数随页码线性上升← 正确答案
  • B.页号越大响应时间越长← 正确答案
  • C.explain 出现 Using filesort← 正确答案
  • D.limit 的数值设置成负数

答案：ABC。深度分页的典型症状是“页号越大越慢”，背后是扫描行数随 offset 线性增长（A、B 对）。filesort 说明排序列没有吃到索引，放大了排序成本（C 对）。limit 为负数（D）是语法错误，不属于性能问题。监控中看到这三类信号，就应启动 keyset 改造。

Q10. 当 order by 字段非唯一时，keyset 使用 > 定位可能出现什么后果？

单选题 · extreme

  • A.排序键相同的行被重复或遗漏← 正确答案
  • B.索引自动变成全表扫描
  • C.查询返回完全乱序
  • D.事务被强制回滚

答案：A。若排序键不唯一，上一页末尾可能与下一页开头存在相同的键值。用 > 会跳过这些相等的行，造成遗漏；若用 >= 又可能重复读到同行。正确做法是用 (sort_key, id) 复合键保证全局唯一。全表扫描、乱序、回滚都与键值重复无直接关系。书签若有重号，定位必然出错。