mysql8.0如何解决深分页查询性能瓶颈_利用延迟关联与书签法优化-mysql教程-PHP中文网

MySQL深分页性能差的根本原因是OFFSET必须扫描并丢弃前N行，优化核心是绕过LIMIT offset,size模型；推荐游标分页（WHERE id>last_id）、延迟关联（子查询取ID再JOIN）或预生成映射表。

mysql8.0如何解决深分页查询性能瓶颈_利用延迟关联与书签法优化

MySQL 8.0 的深分页（如 LIMIT 1000000, 10）不是“慢一点”的问题，而是根本性设计缺陷：它必须扫描并丢弃前 offset 行，无论有没有索引。优化的核心不是调参，而是绕过 LIMIT offset, size 这个执行模型本身。

MySQL 8.0 的优化器对子查询物化（materialization）和半连接（semi-join）的支持更成熟，JOIN 子查询的执行计划更稳定，避免了早期版本中常见的临时表全扫描退化。

必须确保子查询中的 ORDER BY 字段有覆盖索引，否则 SELECT id FROM t ORDER BY create_time LIMIT 1000000, 10 本身就会触发 Using filesort
主表 JOIN 时，ON t.id = tmp.id 必须依赖主键或唯一索引——InnoDB 会走聚簇索引查找，这是 O(log n) 的 B+ 树定位，不是随机 I/O
如果业务允许只查部分字段，把 SELECT t.* 改成 SELECT t.id, t.name, t.status，配合覆盖索引，能进一步消除回表
注意：子查询结果集不能太大，LIMIT 1000000, 10 没问题，但 LIMIT 1000000, 1000 可能导致临时内存不足，建议单页 size ≤ 100

书签法本质是用 WHERE 条件替代 OFFSET，但它不是简单“记住上一页最后 ID”就完事，MySQL 8.0 下要特别注意边界、排序一致性与索引匹配。

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

必须使用单调递增且不重复的字段做书签，id（自增主键）最稳妥；create_time 需加 microsecond 或联合唯一约束，否则并发写入可能产生相同时间戳
排序方向必须与 WHERE 条件严格一致：ORDER BY id ASC 对应 WHERE id > last_id；ORDER BY create_time DESC 对应 WHERE create_time
复合排序场景（如 ORDER BY status, create_time DESC）需用元组比较：WHERE (status, create_time) ，MySQL 8.0 支持该语法，但索引必须是 (status, create_time)
前端传参必须校验：last_id 不能为空、不能为负、不能是非数字字符串，否则可能触发全表扫描

有人试图写成 SELECT t.* FROM t JOIN (SELECT id FROM t WHERE id > ? ORDER BY id LIMIT 10) tmp ON t.id = tmp.id，这看似“双保险”，实则破坏了书签法的 O(1) 复杂度。

子查询里的 WHERE id > ? 已经能精准定位起始位置，再套一层 LIMIT 100000, 10 是冗余的，反而让优化器放弃使用索引范围扫描，降级为全索引扫描
EXPLAIN 会显示 type=range 变成 type=index，key_len 从 8 变成 0，意味着没用上索引的有效长度
真实压测中，这种写法比纯书签法慢 3–5 倍，因为多了一次索引遍历和临时结果集构建
正确做法是二选一：高并发、不允许跳页 → 书签法；需支持跳页、数据无单调字段 → 延迟关联

真正难处理的不是第 100 万页怎么查得快，而是如何让前端不发 page=100000 这种请求——游标 token 和接口限流比任何 SQL 优化都管用。MySQL 8.0 再强，也救不了被滥用的分页语义。