绝大多数数据库不允许子查询中直接使用LIMIT或OFFSET，除非作为FROM子句中的派生表（需别名）；正确做法是将排序子查询转为派生表，外层统一分页，且子查询必须含ORDER BY以保证顺序稳定。
子查询里直接套 LIMIT 和 OFFSET 会报错
绝大多数数据库（MySQL 8.0+、PostgreSQL、SQL Server）不允许在子查询中直接使用 LIMIT 或 OFFSET，除非该子查询是派生表（即出现在 FROM 子句中并带别名）。否则会抛出类似 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 -- ❌ 报错 );
正确做法是把子查询转成派生表，并确保外层有明确的排序和分页逻辑。原因在于：子查询本身不构成“可分页的结果集”，数据库无法在未绑定上下文时确定分页边界。
用派生表 + 外层 LIMIT/OFFSET 实现嵌套分页
核心思路是把带排序的子查询封装为 FROM 中的临时结果集（必须加别名），再在外层统一控制分页。这既绕过语法限制，又保留逻辑完整性。
- 子查询必须包含
ORDER BY，否则派生表顺序不可靠，分页结果会漂移 - 外层
LIMIT/OFFSET才真正生效，子查询里的LIMIT只用于缩减中间集大小（可选优化） - MySQL 支持
LIMIT在派生表内使用（如(SELECT ... LIMIT 100) AS t），但 PostgreSQL 要求子查询先完成再分页，不能依赖内层 LIMIT 控制最终行数
示例（获取“近30天下单用户中活跃度前50名”的第2页，每页10人）：
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 -- ✅ 先筛出候选池，减小 JOIN 开销 ) t ON u.id = t.user_id ORDER BY u.last_login DESC LIMIT 10 OFFSET 10;
WHERE + 子查询结果分页：避免 OFFSET 性能崩盘
当需要“对子查询结果分页”，但子查询本身返回大量 ID（比如百万级用户ID），直接 IN (SELECT ...) + LIMIT/OFFSET 外层会失效——因为 IN 不保序，且数据库可能重排执行计划，导致分页错乱或重复。
更稳的替代方案：
- 用
JOIN替代IN，确保顺序由外层ORDER BY主导 - 若子查询结果需严格按某字段排序分页（如按订单数降序），优先用游标分页：
WHERE order_count + <code>LIMIT 10，而非OFFSET - 对超大子查询结果，考虑物化中间表（
CREATE TEMP TABLE）并建索引，再分页查它 - MySQL 中若子查询含
GROUP BY+HAVING，务必加SQL_CALC_FOUND_ROWS（已弃用）或改用SELECT COUNT(*)单独统计总数
不同数据库对嵌套分页的实际约束
语法看似一致，但底层行为差异极大，容易踩坑：
- MySQL：允许派生表内写
LIMIT，但OFFSET必须在外层；若子查询含UNION，整个联合结果才可被外层分页 - PostgreSQL：子查询必须显式别名，且
ORDER BY必须出现在子查询中（否则报错），外层ORDER BY仍需重新声明才能保证分页稳定性 - SQLite：不支持子查询内
LIMIT，也不支持LIMIT m, n写法，只认LIMIT n OFFSET m，嵌套时务必用派生表 - 所有数据库：若子查询含窗口函数（如
ROW_NUMBER()），可用WHERE rn BETWEEN x AND y替代LIMIT/OFFSET，性能通常更好
最易被忽略的一点：嵌套分页的 ORDER BY 必须全局一致。子查询里按 score DESC 排，外层却按 name ASC 分页，结果既不可预测，也无法用游标延续——这不是语法错误，而是逻辑断裂。
