LIMIT offset, size在多表JOIN后变慢，是因为数据库需先完成全部JOIN、WHERE、ORDER BY生成巨大中间结果集，再跳过offset行；offset越大，扫描丢弃行数越多，性能断崖式下跌。
为什么LIMIT offset, size在多表JOIN后会变慢
因为数据库必须先完成全部JOIN、WHERE、ORDER BY，再跳过offset行才返回结果。一旦关联表数据量大，中间结果集可能达百万级，offset越大，扫描和丢弃的行越多——不是“取第N页”，而是“取前N×size行再扔掉前(N−1)×size行”。
常见现象：LIMIT 10000, 20比LIMIT 0, 20慢几十倍，EXPLAIN 显示rows列暴增，且出现Using temporary; Using filesort。
- JOIN放大行数：比如主表1万行 × 关联表平均5行 = 5万中间行，排序后再
LIMIT 10000,20，实际处理5万+行 - 索引失效：
ORDER BY字段若不在驱动表上，或含函数/表达式，就无法用索引定位起始位置 - 分页深度越大，性能断崖式下跌，不是线性下降
用游标分页（Cursor-based Pagination）替代LIMIT offset
核心思路：不依赖行号偏移，改用上一页最后一条记录的排序字段值作为查询起点，例如WHERE id > ? ORDER BY id LIMIT 20。要求排序字段唯一、有索引、非空（推荐主键或带唯一约束的业务字段）。
多表JOIN时，必须确保游标字段来自驱动表（即FROM后的第一张表），否则无法下推条件。例如：
SELECT u.id, u.name, o.amount FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE u.id > 12345 -- ✅ 游标字段来自驱动表users ORDER BY u.id LIMIT 20
- 若用
o.created_at做游标，但orders不是驱动表，WHERE条件无法下推到orders，仍要先JOIN再过滤 - 复合游标需谨慎：如
WHERE (created_at, id) > (?, ?)，要求联合索引顺序与WHERE一致，且所有字段非NULL - 前端需保存上一页末尾的游标值，不能跳页；适合无限滚动场景，不适合跳转任意页码
子查询先定位ID再JOIN（适用于需要跳页的场景）
把分页逻辑从“全量JOIN后分页”拆成两步：先在驱动表用高效索引分页取出ID列表，再用这些ID反查完整数据。能大幅减少JOIN的数据量。
示例（MySQL）：
SELECT u.*, o.amount FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE u.id IN ( SELECT id FROM users WHERE status = 1 ORDER BY id LIMIT 10000, 20 -- ✅ 这里只操作单表，快 )
- 子查询必须只涉及驱动表字段，且
ORDER BY字段有索引 - MySQL 8.0+ 可用
ROW_NUMBER()窗口函数替代子查询，但注意它仍需全量排序，仅当ID范围可控时更清晰 - 如果关联表有WHERE条件（如
o.status = 'paid'），不能放到外层WHERE，否则会漏数据；应改用LEFT JOIN ... AND或提前在子查询中JOIN聚合
覆盖索引 + 延迟关联（适用于高并发小页长场景）
当只需返回少量字段时，让驱动表的分页查询只走索引（避免回表），再用主键JOIN原表补全其他字段。本质是用空间换时间，减少IO和内存压力。
例如用户列表页只显示id、name、latest_order_amount：
-- 第一步：只查id（覆盖索引） SELECT u.id FROM users u WHERE u.status = 1 ORDER BY u.id LIMIT 10000, 20; <p>-- 第二步：用这20个id查详情（延迟关联） SELECT u.*, o.amount as latest_order_amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.id = ( SELECT id FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1 ) WHERE u.id IN (10001, 10002, ..., 10020);
- 第一步必须命中覆盖索引，比如
INDEX(status, id)，避免Using filesort和Using temporary - 第二步的
IN列表长度受限于max_allowed_packet，超过1000项建议分批或改用临时表 - 关联子查询（如找最新订单）在MySQL中可能被优化为
DEPENDENT SUBQUERY，对每行执行一次；可用JOIN + GROUP BY重写提升稳定性
分页本身不难，难的是在JOIN、过滤、排序、字段需求之间做取舍。游标分页最省资源但牺牲跳页能力；子查询分页兼容传统页码但要注意驱动表边界；覆盖索引方案对字段敏感，加一个没索引的u.email就可能让整个优化失效。真正上线前，务必用真实数据量+慢查询日志验证执行计划。
