mysql查询结果分页执行慢_利用延迟关联优化大数据量分页查询-mysql教程-PHP中文网

OFFSET越大越慢，因MySQL需逐行跳过前N行再取结果；延迟关联通过子查询先取ID再JOIN优化，可减少90%+ I/O，但需确保排序字段加主键防重复。

mysql查询结果分页执行慢_利用延迟关联优化大数据量分页查询

因为 MySQL 在执行这类查询时，必须先扫描并跳过前 10000 行（哪怕只想要后面 20 行），再取结果。如果 id 上有索引，排序快，但“跳过”动作仍要逐行计数；如果没走索引或涉及回表，更慢。数据量越大、偏移量越大，性能断崖式下跌。

常见错误现象：EXPLAIN 显示 rows 高达几十万甚至百万，Extra 里出现 Using filesort 或 Using temporary；实际执行耗时从毫秒级升到秒级甚至十几秒。

核心思路是把“找第 N 页的 ID”和“查这些 ID 对应的完整字段”拆成两步。第一步只走索引，极快；第二步用主键等值 JOIN，也快。

假设表 t 主键为 id，要查第 5001 页（每页 20 条）：

SELECT t.* FROM t INNER JOIN (
  SELECT id FROM t ORDER BY id LIMIT 100000, 20
) AS tmp ON t.id = tmp.id;

对比原始写法：SELECT * FROM t ORDER BY id LIMIT 100000, 20，这个优化能减少 90%+ 的 I/O 和 CPU 消耗（尤其当 t 表有宽字段或 TEXT/BLOB 时）。

ROW_NUMBER() OVER (ORDER BY id) 看起来直观，但实际执行会强制对全表排序并编号，内存/磁盘开销巨大，比 LIMIT OFFSET 更慢，不能用于线上分页场景。

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

下载

正确做法仍是延迟关联；窗口函数更适合“取 TOP N”或“按组排名”，而非分页。

SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) rn FROM t) t1 WHERE rn BETWEEN 100001 AND 100020 —— 这个语句逻辑对，但性能灾难
MySQL 8.0 的 OFFSET 本身没优化，只是语法支持更全，底层执行策略未变
如果业务允许，用游标分页（WHERE id > last_seen_id LIMIT 20）比任何基于 OFFSET 的方案都可靠、快

如果用 ORDER BY create_time，而多行 create_time 相同，MySQL 排序结果不稳定，延迟关联子查询返回的 ID 顺序可能和外层 JOIN 时不一致，导致漏行或重复。

解决方案是在排序字段后追加主键，确保唯一性：

SELECT t.* FROM t INNER JOIN (
  SELECT id FROM t ORDER BY create_time, id LIMIT 100000, 20
) AS tmp ON t.id = tmp.id;

分页慢的本质不是数据多，是 MySQL 不得不“数着走”。延迟关联绕开了数，但前提是排序字段可收敛、关联字段够快。真正上线前，务必用真实数据量 + 真实偏移量跑 EXPLAIN FORMAT=JSON 看 sort_buffer_size 是否溢出、是否用到覆盖索引。

mysql查询结果分页执行慢_利用延迟关联优化大数据量分页查询