外层 limit 不生效是因为子查询未排序且多层嵌套导致 order by 被隔离，优化器无法保证执行顺序，致使分页结果不稳定、重复或错乱；必须扁平化结构并确保 order by 紧邻外层 limit。
MySQL/PostgreSQL 用 LIMIT + 子查询分页时，为什么外层 LIMIT 不生效？
因为子查询本身没排序、没限制，数据库可能把 LIMIT 下推失败，或优化器重排执行顺序，导致外层 LIMIT 实际作用在未排序的中间结果上。最典型的现象是：分页返回行数不稳定、顺序错乱、甚至重复。
必须确保子查询带 ORDER BY，且外层 LIMIT 紧跟其后——不能隔一层无意义的包装：
- ✅ 正确（子查询有序，外层直接截取）：
SELECT * FROM (SELECT * FROM orders WHERE status = 'shipped' ORDER BY created_at DESC) t LIMIT 10 OFFSET 20 - ❌ 错误（多套一层，
ORDER BY被隔离）：SELECT * FROM (SELECT * FROM (SELECT * FROM orders WHERE status = 'shipped') t1 ORDER BY created_at DESC) t2 LIMIT 10 OFFSET 20—— 内层子查询没ORDER BY，t1结果无序，t2排序已晚 - ⚠️ 注意：MySQL 5.7 及更早版本对多层嵌套中
ORDER BY的下推支持较弱，建议扁平化写法
SQL Server 用 ROW_NUMBER() 嵌套分页，WHERE 条件漏写会怎样？
漏写会导致分页逻辑彻底失效：外层 WHERE rn BETWEEN X AND Y 过滤的是“全表加序号后的行号”，而非“过滤后数据的行号”。比如查状态为 shipped 的第 2 页（每页 10 条），若只在外层加 WHERE status = 'shipped'，而内层没加，ROW_NUMBER() 就会给所有订单编号，rn = 11 可能对应一个 pending 订单。
正确做法是把业务条件全部塞进最内层查询：
- ✅ 正确：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM orders WHERE status = 'shipped') t WHERE t.rn BETWEEN 11 AND 20 - ❌ 错误：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM orders) t WHERE t.status = 'shipped' AND t.rn BETWEEN 11 AND 20——rn已按全表排好，status过滤发生在编号之后 - ? 提示：SQL Server 2012+ 优先用
OFFSET-FETCH，语义更清晰、不易出错；ROW_NUMBER()仅用于需同时返回总行数等复杂场景
PostgreSQL 中嵌套窗口函数 + LIMIT，total_count 怎么不出错？
COUNT(*) OVER() 必须和主查询的 WHERE 条件严格一致，否则 total_count 是全量计数，而实际返回行数只是子集。例如你只想查最近 30 天的订单，但 OVER() 没加时间过滤，总数就包含历史所有记录。
关键点是：窗口函数作用域由当前查询层级决定，不继承外层条件：
- ✅ 正确（内外 WHERE 一致）：
SELECT id, amount, total_count FROM (SELECT id, amount, COUNT(*) OVER() AS total_count FROM orders WHERE created_at >= NOW() - INTERVAL '30 days' ORDER BY id) t LIMIT 10 - ❌ 错误（窗口无 WHERE）：
SELECT id, amount, total_count FROM (SELECT id, amount, COUNT(*) OVER() AS total_count FROM orders ORDER BY id) t WHERE t.created_at >= NOW() - INTERVAL '30 days' LIMIT 10——total_count是全表订单数 - ⚠️ 注意：PostgreSQL 允许
LIMIT和窗口函数共存，但 MySQL 8.0 之前不支持，必须拆成两层查询
Oracle ROWNUM 嵌套分页，为什么第二层写 ROWNUM 更快？
因为 Oracle 优化器能把第二层的 ROWNUM 条件“推入”最内层查询，让扫描在达到阈值时提前终止；而如果只在外层写 <code>ROWNUM BETWEEN M AND N，内层必须先产出全部结果，再编号、再过滤，IO 和内存开销翻倍。
实操上要严格遵循三层结构：
- ✅ 高效写法（推荐）：
SELECT * FROM (SELECT a.*, ROWNUM rn FROM (SELECT * FROM orders WHERE status = 'shipped' ORDER BY id) a WHERE ROWNUM = 21 - ❌ 低效写法：
SELECT * FROM (SELECT a.*, ROWNUM rn FROM (SELECT * FROM orders WHERE status = 'shipped' ORDER BY id) a) WHERE rn BETWEEN 21 AND 30 - ? Oracle 12c+ 直接用
OFFSET-FETCH，无需手写 ROWNUM 嵌套，更安全；老版本务必保证WHERE ROWNUM 出现在第二层
嵌套分页真正难的不是语法，而是每一层的过滤边界是否对齐、排序是否可控、以及数据库是否真把你的意图编译进了执行计划——尤其当子查询里还混着 JOIN 或聚合时，EXPLAIN 看一眼 rows 和 Extra 字段，比背十遍语法管用。
