先JOIN再ORDER BY LIMIT会变慢，因为MySQL必须先完成大表关联、再在大量结果上排序并跳过前N行，无法利用覆盖索引，易触发临时表或文件排序；延迟关联通过先用联合索引查ID再JOIN补字段，将排序分页与关联解耦，显著降低I/O和CPU开销。
为什么先JOIN再ORDER BY LIMIT会变慢
常见写法是把JOIN、WHERE、ORDER BY、LIMIT全堆在一起，比如：SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 1 ORDER BY o.created_at DESC LIMIT 1000, 20。这种写法的问题在于：MySQL必须先完成JOIN（可能触发大表全关联），再在几万行结果上排序+跳过1000条——哪怕orders上有status和created_at的联合索引，JOIN也会让优化器放弃使用覆盖索引，转而走临时表或文件排序。
用延迟关联把JOIN拆到分页之后
核心是把“排序分页”和“取详情”两步解耦：先在主表（orders）里用索引快速定位目标ID，再拿这些ID去JOIN补字段。这样排序只发生在轻量的主键列上，不涉及大字段回表或关联开销。
- 确保
orders表有覆盖过滤和排序的联合索引，例如：ALTER TABLE orders ADD INDEX idx_status_created_id (status, created_at DESC, id) - 子查询只查
id，强制走索引扫描，无回表、无临时表：SELECT id FROM orders WHERE status = 1 ORDER BY created_at DESC LIMIT 1000, 20 - 外层JOIN基于主键，效率高且可控：
SELECT o.*, u.name FROM orders o INNER JOIN users u ON o.user_id = u.id INNER JOIN (上面子查询) AS tmp ON o.id = tmp.id - 如果
users表很大，且只需要name，建议给users(id, name)建覆盖索引，避免对users回表
当JOIN条件字段没索引时，性能会断崖下跌
延迟关联的前提是JOIN字段有高效索引。如果users.id没主键或没索引，外层JOIN就会变成对users表的嵌套循环扫描，反而比原写法更慢。
- 检查执行计划：
EXPLAIN中users表的type必须是const、eq_ref或至少ref；若出现ALL或index，说明缺失索引 -
user_id在orders表上必须是索引前缀（如idx_status_created_id已含status和created_at，但不含user_id），否则子查询无法提前过滤用户维度 - 若业务允许，可把常用JOIN字段冗余进主表（如
users.name冗余为orders.user_name），彻底消除JOIN——适合读多写少、一致性要求不苛刻的场景
游标分页 + 延迟关联才是深分页的稳态解
当OFFSET超过5万，即使用了延迟关联，子查询里的LIMIT 50000, 20仍要跳过5万行，I/O压力不小。这时必须切换到游标分页，把“第N页”逻辑替换为“从某条记录之后取20条”。
- 第一版游标需包含足够去重的字段组合，例如：
ORDER BY created_at DESC, id DESC，对应WHERE条件写成：WHERE (created_at, id) - 游标值必须来自上一页最后一条真实数据，不能靠计算或客户端生成，否则可能漏/重
- 游标分页后，延迟关联依然适用：子查询用游标条件查
id，外层再JOIN，两层都避开OFFSET - 注意：MySQL 5.7不支持行构造器比较（即
(a,b) ），得拆成<code>created_at
真正卡住性能的往往不是JOIN本身，而是让JOIN参与了本不该它承担的排序与跳过动作。把分页逻辑锁死在主表索引内，才是可控的起点。
