为什么MySQL LIMIT深分页会越来越慢-mysql教程-PHP中文网

mysql执行limit offset, size时并非跳转而是顺序扫描并丢弃前offset行，导致性能随offset线性下降；优化需采用延迟关联（子查询取主键再join）或游标分页（where > 上一页末值），且必须配合正确索引设计。

为什么mysql limit深分页会越来越慢

MySQL执行`LIMIT offset, size`时真不是“跳”而是“扫+丢”

很多人以为LIMIT 1000000, 20会让MySQL直接定位到第1000001行——实际完全相反：它必须从索引起点开始，逐行扫描、计数，直到凑够1000020条才停，再把前1000000条全扔掉。被丢弃的每一行都要走完整路径：读页、解包、回表（如果没覆盖索引）、进缓冲池，甚至触发Using filesort或写临时文件。

这导致：

EXPLAIN里的rows值总是offset + size，不是size
即使id是主键，ORDER BY created_at LIMIT 1000000, 20也大概率不走id索引——除非created_at有对应索引
优化器可能判断“全表顺序扫描比走索引+回表100万次更快”，于是降级为type: ALL

延迟关联（Deferred Join）怎么绕过深分页瓶颈

核心思路是把“排序+跳过+取全字段”拆成两步：先用轻量子查询只拿id（走覆盖索引），再用这些id精准回表。避免大字段和非索引列拖慢扫描路径。

正确写法示例：

SELECT o.* FROM orders o
INNER JOIN (SELECT id FROM orders ORDER BY create_time DESC LIMIT 1000000, 20) AS tmp
ON o.id = tmp.id

注意：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

子查询必须用主键或唯一键（如id）匹配，否则MySQL 8.0.22之前会报错
IN不能替代JOIN——MySQL明确禁止带LIMIT的子查询用于IN条件
复合索引如INDEX (create_time DESC, id)能让子查询只走索引，避免回表

游标分页为什么能保持恒定响应时间

WHERE create_time 这类写法，彻底去掉<code>OFFSET，靠上一页末尾记录的排序键作为下一页起点。MySQL只需在索引中找到那个位置，往后取20条，时间复杂度接近O(1)。

但必须满足：

排序字段组合必须唯一且单调，比如(create_time DESC, id DESC)——否则可能漏数据或重复
前端必须保存上一页末尾的完整排序键（不止一个字段），不能只存create_time
不支持跳页（如直接翻到第100页），只适用于“下一页”“上一页”或无限滚动

最容易被忽略的其实是索引设计本身

换写法没用，如果索引没对齐查询模式，延迟关联和游标分页都白搭。比如用create_time分页，却只给id建了主键索引——那所有优化都会失效。

真正要检查的是：

你的ORDER BY字段是否有对应索引？是否是复合索引的最左前缀？
查询里WHERE条件字段是否和排序字段一起进了联合索引？例如WHERE user_id = ? ORDER BY create_time，索引应建为INDEX (user_id, create_time)
是否用了SELECT *？如果是，确保索引能覆盖查询所需字段，否则回表开销会吃掉所有优化收益

索引、排序、查询条件三者必须对齐，否则再花哨的分页技巧也只是隔靴搔痒。