MySQL执行大offset分页时需扫描跳过大量数据，引发回表、I/O和排序开销，导致查询变慢；应改用游标分页（WHERE id > last_id）避免OFFSET。
为什么 LIMIT offset, size 越大，Navicat 查询越卡
不是 navicat 慢，是 mysql 在执行 limit 1000000, 20 这类语句时，必须从索引头开始扫描并跳过前 100 万行——哪怕这些行根本不会返回。每跳过一行，都可能触发回表、i/o、排序或临时文件写入。navicat 只是把这条 sql 发过去，然后等结果；它卡住，是因为 mysql 还没算完。
常见错误现象：EXPLAIN 显示 rows 值随 offset 线性增长；Handler_read_next 指标暴涨；Navicat 界面无响应超过 30 秒，甚至弹出“查询超时”提示。
- 即使
ORDER BY id有主键索引，优化器仍可能因统计信息陈旧或谓词复杂放弃索引覆盖扫描 -
SELECT *+ 大 offset 会放大回表代价：每跳过的行都可能引发一次随机 I/O -
sort_buffer_size不足时，排序阶段会落盘，性能断崖下跌
Navicat 里直接改 SQL 用游标分页（WHERE id > last_id）
这是最立竿见影的改法，适合 Feed 流、订单列表、日志查看等“向下滚动”场景。核心是绕开 OFFSET，改用有序字段做边界判断。
第一页：SELECT * FROM orders WHERE status = 'paid' ORDER BY id LIMIT 20
拿到最后一条的 id = 105872 后，第二页写成：SELECT * FROM orders WHERE status = 'paid' AND id > 105872 ORDER BY id LIMIT 20
- 排序字段必须单调且唯一；推荐用主键，或
created_at DESC, id DESC组合（WHERE 条件也得同步写成created_at ） - Navicat 中只需手动粘贴执行，无需额外配置；但不能用「运行SQL文件」功能——它会拆语句、忽略 WHERE 边界
- 缺点：不支持跳转任意页码（比如直接输“第 500 页”），只适合连续下拉
如果必须支持跳页（比如后台管理页码输入框）
用延迟关联（Deferred Join）是最务实的 SQL 层补救方案。原理是：先用覆盖索引快速捞出要的 ID，再用这些 ID 批量回查全字段。
原慢查询：SELECT * FROM articles WHERE category_id = 5 ORDER BY created_at DESC LIMIT 10000, 20
优化后：SELECT a.* FROM articles a INNER JOIN (SELECT id FROM articles WHERE category_id = 5 ORDER BY created_at DESC LIMIT 10000, 20) t ON a.id = t.id
- 前提：
(category_id, created_at)必须有联合索引，且子查询只查id（否则子查询本身也会回表） - Navicat 中执行前务必确认：子查询部分能走
type=range、key非空、Extra不含Using filesort或Using temporary - 效果明显，但不如游标分页稳定；当 offset 超过 50 万时，子查询仍可能变慢
Navicat 自身执行机制带来的隐性拖累
即使 SQL 已优化，Navicat 的 GUI 层仍可能让查询“看起来更慢”：它默认逐条解析、渲染、缓存元数据，对大结果集尤其吃资源。
- 避免用「运行SQL文件」导入大量 INSERT；改用命令行：
mysql -u root -p db_name ，并提前加 <code>SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0; SET autocommit=0; - 在「新建查询」窗口中执行，不要勾选「执行前验证语法」——500MB 文件可能卡死在预解析阶段
- 关掉「自动完成」和「语法高亮」能减轻 CPU 压力，但治标不治本；真正瓶颈永远在 SQL 逻辑和索引设计上
最容易被忽略的一点：游标分页的 WHERE 条件必须和 ORDER BY 字段严格对齐，少一个等号、错一个方向，就退化回全表扫描。别假设“反正有索引”，一定要用 EXPLAIN 看一眼 key 和 rows。
