深度分页（如 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 页”改成“我要比上一页最后一条记录更新的数据”，绕过偏移计算。
- 要求：必须有单调、唯一、有索引的字段（通常是主键
id或时间戳created_at）- 原查询：
SELECT * FROM orders ORDER BY id DESC LIMIT 100000, 20- 改写后：
SELECT * FROM orders WHERE id （假设上一页最后一条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降到了百级，你就知道，那几十万行的“路过”已经被真正砍掉了。
怎样在Navicat中利用执行计划优化深度分页查询？
老辰吖_7034
2026-11-01
833人浏览
原创
