根本原因是mysql必须扫描并丢弃前offset行，而非跳过；优化方案是用where id > ? order by id limit n替代limit m, n，前提是主键或时间字段有序。
limit 分页越往后越慢，根本原因是 mysql 必须扫描并丢弃前 offset 行，不是跳过，而是真读、真过滤、真扔掉。 千万级表查 limit 9000000, 50，就得定位到第 9000050 条记录，中间所有行都参与了索引遍历或回表——这和你要的 50 条无关，纯属浪费。
为什么 LIMIT m, n 的执行时间随 m 线性增长
MySQL 没有“直接跳到第 m 行”的能力。它依赖 B+ 树的有序遍历：从起点开始逐条计数，直到累计满足 m + n 条才停止。即使有主键索引，id > 9000000 是范围扫描，而 LIMIT 9000000, 50 是深度偏移扫描，后者要走完整条索引链路前 9000000 个节点。
- 实测对比（千万级表）：
SELECT * FROM t_order LIMIT 0, 10耗时 0.002s；SELECT * FROM t_order LIMIT 10000000, 10耗时 4.134s - 执行计划里
rows字段会显示扫描行数，它 ≈m + n，不是n - 如果
WHERE条件本身没走索引，还叠加LIMIT，性能雪上加霜
用 WHERE id > ? LIMIT n 替代 LIMIT m, n
这是最常用也最有效的优化手段，前提是表有单调递增/递减的有序主键（如 id）或业务时间字段（如 create_time），且查询按该字段排序。
- 把“第 N 页”转为“上次查到的最后
id之后的下一批”：SELECT * FROM t_order WHERE id > 9000000 ORDER BY id LIMIT 50 - 首次查询需先取最小
id：SELECT MIN(id) FROM t_order，或用ORDER BY id LIMIT 1 - 必须确保
WHERE id > ?和ORDER BY id同一字段，否则可能漏数据或重复 - Navicat 中手动分页时，可复制上一页最后一条的
id值，粘贴进下一条 SQL，比输数字偏移更可靠
Navicat 客户端侧能做的实际优化
Navicat 本身不改 SQL 逻辑，但它的设置和操作习惯直接影响你感知到的“卡顿”。别让客户端拖慢诊断节奏。
- 禁用“自动获取表结构信息”和“自动展开外键/索引”：右键连接 → Connection Properties → 取消勾选
Retrieve table structure information automatically - 调大查询超时：菜单 Tools → Options → Connection → 把
Query timeout (seconds)改成 60 或更高（避免中途断连） - 关掉“结果网格中显示 BLOB 内容”：BLOB 字段（如图片、JSON）全量加载会阻塞渲染，尤其分页查宽表时
- 用 Explain 按钮（闪电图标）看执行计划，确认是否走了索引、
rows是否合理，而不是只盯“耗时”数字
真正难的是无序字段分页（比如按热度、评分、模糊匹配结果排序），此时 id > ? 失效，必须依赖覆盖索引 + 子查询或游标分页（WHERE (score, id) > (?, ?)）。这类场景没有银弹，得结合业务容忍度权衡——要么接受前端“只允许翻前 100 页”，要么后端改用 Elasticsearch 等专为分页设计的引擎。
