深度分页（如 LIMIT 100000, 20）性能差是因 MySQL 必须跳过前 offset 行，即使走索引也导致高 I/O；游标分页通过 WHERE id

深度分页（如 LIMIT 100000, 20）在 Navicat 中直接执行时，即使有索引，也极大概率触发全表扫描或高成本索引遍历——这不是你的 SQL 写错了，而是 MySQL 优化器面对大偏移量时的固有限制。

为什么 LIMIT offset, size 在大 offset 下会变慢

MySQL 必须先定位到第 offset + 1 行，再取 size 行。哪怕走的是索引，它仍要“跳过”前 offset 行——rows 值会暴增，type 可能仍是 range，但实际 I/O 和 CPU 消耗已失控。

• EXPLAIN 显示 rows = 100020，不代表只读 100020 行，而是优化器预估要“路过”这么多索引节点才能落地
• Extra 出现 Using index 是假象：它只是说用了索引，没说跳过了多少无效节点
• 如果 ORDER BY id 字段未包含在索引最左前缀中，还会叠加 Using filesort，性能雪上加霜

用游标分页（cursor-based pagination）替代 LIMIT offset, size

本质是把“我要第 N 页”改成“我要比上一页最后一条记录更新的数据”，绕过偏移计算。

navicatmysql

Navicat For MySQL

下载

• 要求：必须有单调、唯一、有索引的字段（通常是主键 id 或时间戳 created_at）
• 原查询：SELECT * FROM orders ORDER BY id DESC LIMIT 100000, 20
• 改写后：SELECT * FROM orders WHERE id （假设上一页最后一条 <code>id = 543210）
• 在 Navicat 中执行改写后的语句 → 点“解释” → 确认 type = range、key 命中主键、rows 落在几百以内

Navicat 里验证游标分页是否真正生效

不能只看查询快了没，得确认执行路径确实轻量。

• 检查 key 列是否等于你期望的索引名（如 PRIMARY），而不是 NULL 或其他二级索引
• rows 值应接近 20（或略高），而非数十万；若仍为 10 万+，说明 WHERE id 条件未被索引覆盖（比如字段类型不一致导致隐式转换）
• Extra 中不应出现 Using filesort；如果 ORDER BY 字段和 WHERE 字段不是同一索引的一部分，就会触发它
• 对复合排序（如 ORDER BY status, created_at DESC），索引必须是 (status, created_at)，且 WHERE 必须含 status = ? 才能避免 filesort

当必须用传统分页时，如何让 Navicat 的执行计划暴露真实瓶颈

Navicat 默认的 EXPLAIN 不反映实际执行开销，容易误判。

• 别只信 rows：它是采样估算值，表刚批量导入后可能严重失真；运行 ANALYZE TABLE orders 再解释一次
• 开启 JSON 格式看成本：EXPLAIN FORMAT=JSON SELECT ... → 关注 cost_info.query_cost，对比不同写法的绝对数值差异
• 警惕“假索引”：possible_keys 有值但 key 为空，说明优化器看到索引却弃用——常见于统计信息不准，或 WHERE 条件选择性太差（如 status IN ('pending', 'processing') 占全表 80%）
• 如果业务强依赖深度页码（如后台导出第 500 页），考虑加覆盖索引：CREATE INDEX idx_cover ON orders (status, created_at, id)，把 SELECT 字段也塞进索引减少回表

游标分页不是银弹——它要求前端记住上一页末位值，且无法跳转任意页码。但只要 Navicat 里 EXPLAIN 显示 rows 降到了百级，你就知道，那几十万行的“路过”已经被真正砍掉了。