绝大多数数据库不允许子查询中直接使用LIMIT或OFFSET，必须将子查询转为FROM子句中的派生表并加别名，外层统一分页，且子查询必须含ORDER BY以保证顺序稳定。
子查询里不能直接写 LIMIT 和 OFFSET
绝大多数数据库（MySQL 8.0+、PostgreSQL、SQL Server）会在你尝试这样写时直接报错：ERROR: LIMIT/OFFSET not allowed in subqueries。比如：
SELECT * FROM users WHERE id IN ( SELECT id FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 20 -- ❌ 语法错误 );
原因很简单：子查询不是“结果集上下文”，数据库无法保证它在嵌套中被当作有序可分页的序列来处理。哪怕你加了 ORDER BY，只要没出现在 FROM 子句里，LIMIT 就不合法。
必须用派生表（Derived Table）包装子查询
正确做法是把排序后的子查询变成 FROM 中的临时表，并给它起别名。外层再统一控制分页逻辑：
SELECT u.* FROM users u INNER JOIN ( SELECT DISTINCT user_id FROM orders WHERE created_at >= NOW() - INTERVAL '30 days' ORDER BY COUNT(*) DESC, MAX(created_at) DESC LIMIT 50 -- ✅ 允许：这是派生表内部的预筛选，非最终分页 ) t ON u.id = t.user_id ORDER BY u.last_login DESC LIMIT 10 OFFSET 10; -- ✅ 真正生效的分页在这里
- 子查询必须带
ORDER BY，否则派生表顺序不可靠，分页结果会漂移 -
LIMIT放在派生表里只是优化手段（减少 JOIN 数据量），不能替代外层分页 - PostgreSQL 对派生表内
LIMIT更严格——它要求子查询先完整执行完再分页；MySQL 允许但不推荐依赖它控制最终行数
IN + 子查询分页会失效，改用 JOIN 或游标
当你想对“子查询返回的 ID 列表”分页，比如百万级用户 ID，直接写 WHERE id IN (SELECT ...) 再套 LIMIT/OFFSET 是危险的：
-
IN不保序，数据库可能重排执行计划，导致第 2 页出现重复或遗漏 - 深分页（如
OFFSET 100000）性能崩盘，因为仍要扫描前 10 万行 - 并发写入下，数据变动会让
OFFSET分页结果错位
更稳的做法：
- 用
JOIN替代IN，确保外层ORDER BY主导顺序 - 改用游标分页：比如按
order_count DESC, user_id DESC排序后，第 2 页条件写成WHERE (order_count, user_id) + <code>LIMIT 10 - 超大数据量时，先物化中间结果：
CREATE TEMP TABLE tmp_users AS SELECT ...，建索引后再分页查
ORDER BY 缺失是分页最大隐患
哪怕语法通过，漏掉 ORDER BY 也会让分页失去意义：
- 数据库不保证无序查询的行返回顺序，两次
LIMIT 10 OFFSET 10可能返回不同数据 - 复合排序字段必须唯一组合，否则相同值的行顺序不确定（例如只按
status DESC分页，多个 status=1 的记录可能每次位置乱跳） - 建议补一个唯一字段兜底：
ORDER BY created_at DESC, id DESC
真正要命的不是不会写 LIMIT，而是以为加了它就万事大吉——顺序没锚定，分页就是空中楼阁。
