join后直接用limit offset会变慢，因为数据库必须先完成所有表join、where过滤和order by排序，生成庞大中间结果集后再丢弃offset行；延迟关联通过先查主键再join解耦分页与关联，游标分页则用上一页末尾排序值作为where条件实现索引范围查询，避免全量扫描。
为什么JOIN后直接用LIMIT OFFSET会变慢
因为数据库必须先把所有表JOIN完、执行WHERE过滤、再对完整中间结果集做ORDER BY排序，最后才跳过OFFSET行——中间结果集可能比主表大几倍。比如1万订单平均关联5条明细，JOIN后就是5万行；OFFSET 40000时，数据库实际要扫描并丢弃前40000条“组合记录”，不是40000个订单。
EXPLAIN里看到Using temporary; Using filesort就说明出问题了
这代表数据库无法复用单表索引完成JOIN后的排序，被迫创建临时表+文件排序。常见诱因包括：
-
ORDER BY字段不在驱动表上，或含函数（如ORDER BY DATE(created_at)） - JOIN条件字段没索引，导致优化器放弃索引下推
- 子查询里提前写了
JOIN或用了从表字段，破坏了分页逻辑下推
延迟关联（Deferred Join）怎么写才有效
核心是把分页和JOIN解耦：先用主表索引快速取出ID，再拿这些ID去补数据。必须满足三个硬性条件：
- 子查询只查主表
id（或主键），且ORDER BY字段有索引（如created_at） - 子查询里不能出现任何从表字段、
JOIN、GROUP BY或函数表达式 - 外层
JOIN必须用主表id关联，且关联字段要有索引（如users.id是主键）
错误示例：SELECT o.id FROM orders o JOIN users u ON o.user_id = u.id——这会让优化器退回全量JOIN。
游标分页为什么能绕过OFFSET的线性开销
它不依赖“跳过多少行”，而是用上一页最后一条记录的排序值作为查询起点，例如WHERE created_at 。关键约束：
- 游标字段必须来自驱动表（即
FROM后的第一张表），否则WHERE条件无法下推 - 排序字段必须严格单调、非空、有索引；推荐用
(created_at, id)组合，且建联合索引idx_status_created_id - 前端必须保存上一页末尾的游标值，不能跳页；适合无限滚动，不适合后台跳转任意页码
真正容易被忽略的是：即使用了游标，如果WHERE条件里的游标值传错（比如精度丢失、时区不一致），结果就会漏数据或重复——这个细节在联调时经常被绕过。
