直接在JOIN结果上用LIMIT OFFSET会变慢，因为数据库必须先完成所有JOIN、WHERE和ORDER BY，生成远大于主表的中间结果集，再扫描并丢弃前OFFSET行；正确做法是先分页主表（子查询只查带索引排序的id）、再JOIN，且排序需用唯一组合字段保证稳定。
为什么直接在JOIN结果上用LIMIT OFFSET会变慢
因为数据库必须先把所有表 JOIN 完、应用 WHERE、执行 ORDER BY，生成完整中间结果集后，才开始跳过 OFFSET 行——中间结果集可能比主表大几倍（比如一个订单关联 5 条明细，1 万订单就变成 5 万行），LIMIT 10000, 20 实际要扫描并丢弃前 10000 行“组合记录”，不是 10000 个订单。你看到的慢，本质是重复扫描和丢弃。
怎么写“先分页主表再JOIN”才真正有效
关键不在语法嵌套，而在是否让数据库把分页逻辑下推到主表索引扫描阶段。必须满足三个条件：
- 子查询只查主表的
id（或主键列），且ORDER BY字段有索引（如created_at） - 子查询里不能出现任何从表字段、
JOIN、GROUP BY或函数表达式 - 外层
JOIN必须用主表id关联，不能改用其他字段（否则无法走主键索引）
正确示例：
SELECT o.*, u.name, p.title FROM orders o INNER JOIN ( SELECT id FROM orders WHERE status = 1 ORDER BY created_at DESC, id DESC LIMIT 20 OFFSET 40000 ) AS page_ids ON o.id = page_ids.id LEFT JOIN users u ON o.user_id = u.id LEFT JOIN products p ON o.product_id = p.id;
错误写法：SELECT o.id FROM orders o JOIN users u … —— 这会让优化器放弃索引下推，回到全量 JOIN 后分页的老路。
ORDER BY 字段重复时数据错位怎么办
如果仅按 created_at DESC 排序，多个订单时间相同，OFFSET 40000 可能每次取到不同行（排序不稳定）。解决方案是强制加入唯一字段补全排序依据：
- 用
ORDER BY created_at DESC, id DESC（推荐，id主键天然唯一） - 确保该组合有联合索引：
CREATE INDEX idx_status_created_id ON orders(status, created_at, id) - 子查询和外层查询的
ORDER BY必须完全一致，否则外层排序会打乱子查询的偏移逻辑 - 不要用
ORDER BY created_at DESC, RAND()或函数，会导致索引失效
什么时候该换游标分页而不是死磕OFFSET
当偏移量持续增长（比如用户不断点击“下一页”）、且前端只支持“下一页”时，游标分页比任何 LIMIT offset 方案都可靠。它不依赖行号，而是用上一页末尾的 id 值做边界条件，起点可直接通过索引定位。
典型写法：
SELECT o.*, u.name, p.title FROM orders o LEFT JOIN users u ON o.user_id = u.id LEFT JOIN products p ON o.product_id = p.id WHERE o.created_at < '2025-03-15 10:22:33' OR (o.created_at = '2025-03-15 10:22:33' AND o.id < 12345) ORDER BY o.created_at DESC, o.id DESC LIMIT 20;
注意：游标分页要求排序字段严格单调或有确定性组合，且必须维护上一页最后一条记录的完整排序键值——这个细节最容易被忽略，一漏就导致跳页或重复。
