MySQL执行LIMIT OFFSET需逐行扫描前N行，无法跳过；ORDER BY无索引或复合索引顺序不匹配会导致全表扫描和filesort；分页应避免大offset，改用游标式查询（如WHERE create_time

MySQL执行LIMIT OFFSET时必须逐行扫描前N行

MySQL不会“跳到第100001行”，而是从排序结果的第一行开始，老老实实数到第100001行才开始取数据。哪怕你只想要20条，它也得先把前100000条全读一遍、比对一遍、再扔掉——这些行不返回，但CPU和IO全花了。

常见错误现象包括：EXPLAIN显示rows高达几十万甚至上百万，Extra里出现Using filesort或Using index却依然卡顿；LIMIT 0,20毫秒级，LIMIT 99980,20直接超时。

关键点在于：这个“丢弃”动作无法被索引跳过。B+树索引存的是key → row映射，不是“第N行在哪”的随机访问地址。就算有ORDER BY id和主键索引，MySQL仍需遍历约offset个叶子节点才能定位起点。

ORDER BY字段没索引或不匹配会导致全表扫描

如果ORDER BY create_time DESC没建索引，或者WHERE条件和ORDER BY字段无法共用同一个复合索引，MySQL就不得不先做Using filesort：把所有满足WHERE的数据捞出来，在内存或磁盘临时排序，再丢前N行——这时扫描行数可能远超offset+size，而是整个符合条件的结果集大小。

使用场景中容易忽略的细节：

• 复合索引顺序必须匹配查询逻辑，比如WHERE status = 1 ORDER BY create_time DESC，索引应建为(status, create_time)，而不是反过来
• create_time若存在大量重复值，仅靠它分页会漏数据或重复，必须叠加主键（如WHERE create_time ）
• 时间字段用DATETIME而非TIMESTAMP更稳妥，避免时区转换引发隐式类型转换失效索引

游标分页为什么快：把“跳过N行”变成“从某值开始查”

游标分页绕开了offset的线性代价，核心是用上一页末尾的排序字段值作为下一页的WHERE条件起点。只要该字段有索引、可比较、且业务允许顺序翻页，性能就是常数级。

MySQL8 CRM Schema Design Expert

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

下载

实操建议：

• ID升序分页：上一页最后id是6800000，下一页写WHERE id > 6800000 ORDER BY id LIMIT 20
• 时间倒序分页：上一页最后updated_at是'2026-04-10 15:22:33'，下一页写WHERE updated_at
• 务必在ORDER BY字段上建索引，否则WHERE条件无法高效过滤，游标就失去意义

非要支持任意页码跳转？延迟关联能减回表但不治本

当后台管理必须输入“第892页”时，游标不适用，只能用延迟关联：先用覆盖索引查ID，再JOIN回原表取全量字段。它不减少扫描行数，但大幅降低单行IO成本——因为子查询只读id，不读text、json等大字段。

典型写法：

SELECT o.* 
FROM orders o 
INNER JOIN (
  SELECT id FROM orders WHERE status = 1 ORDER BY id LIMIT 1000000, 20
) t ON o.id = t.id;

容易踩的坑：

• 子查询里不能写SELECT *，否则失去覆盖索引优势
• 外层JOIN字段必须有索引（主键天然满足），否则JOIN变嵌套循环，更慢
• 如果status = 1筛选后数据仍超百万，这个方案收益有限，此时应优先考虑归档冷数据或加缓存

真正难处理的不是技术方案本身，而是业务是否接受“不能跳页”。很多所谓“必须支持跳转”的需求，其实是前端没做防呆，或者运营人员不知道下拉加载更稳——而一旦接受游标，性能提升往往是几十倍起跳。