rownum > n 查询不到数据是因为 rownum 在 oracle 中动态顺序赋值，从 1 开始，每行生成后立即判断 where 条件；若条件为 rownum > 10，首行 rownum=1 不满足即被丢弃，后续行无法获得更高级别 rownum，故结果为空。
为什么直接用 ROWNUM > N 会查不到数据
因为 ROWNUM 是 Oracle 在结果集生成过程中**动态、顺序赋值**的伪列，它从 1 开始，每返回一行就加 1。关键点在于：Oracle 先取第一行、赋 ROWNUM = 1，再判断 WHERE 条件；如果条件是 ROWNUM > 10，这一行立刻被丢弃，后续行永远拿不到 ROWNUM = 2（因为第一行都没过筛），整个结果为空。
所以你不能写 SELECT * FROM t WHERE ROWNUM > 10，也不能写 ROWNUM = 5——这些在语法上合法，但逻辑上永远不成立。
-
ROWNUM只能用于或 <code>= 1这类“上限”或“首行”判断 - 想跳过前 N 行，必须靠子查询把
ROWNUM“固化”成一个普通列名（如rnum），再在外层过滤 - 排序必须放在最内层子查询里，否则
ROWNUM会按原始扫描顺序编号，导致分页错乱
三层嵌套结构怎么写才不翻车
标准三层结构不是为了炫技，而是为了解耦「排序」「编号」「截断」三个动作。每一层各干一件事，缺一不可：
第一层（最内）：只做 ORDER BY，确保数据有序；不能带 ROWNUM，也不能有分页逻辑
第二层（中间）：对已排序结果加 ROWNUM，并用 WHERE ROWNUM 提前截断，避免全表编号——这是性能关键
第三层（最外）：把第二层的 ROWNUM 当作普通列（比如叫 rnum），用 WHERE rnum > :min_row 筛出目标页
SELECT *
FROM (
SELECT a.*, ROWNUM rnum
FROM (
SELECT * FROM employees ORDER BY hire_date DESC
) a
WHERE ROWNUM 20;
- 若把
ORDER BY放到第二层或第三层，ROWNUM编号早已完成，排序无效 - 若省略第二层的
WHERE ROWNUM ，Oracle 会对全表排序后编号，大数据量下极慢 - 页码参数计算：第
n页（每页m条）→:min_row = (n-1)*m，:max_row = n*m
ROW_NUMBER() 分析函数比 ROWNUM 好在哪
ROW_NUMBER() OVER (ORDER BY ...) 是标准 SQL 窗口函数，在 Oracle 9i 就支持，它和 ROWNUM 的根本区别在于：它先完成全部排序，再统一编号，因此可直接用于 BETWEEN 或 > 判断，无需嵌套。
SELECT * FROM ( SELECT e.*, ROW_NUMBER() OVER (ORDER BY salary DESC) rn FROM employees e ) WHERE rn BETWEEN 21 AND 30;
- 语义清晰：不用记“哪层该写什么”，逻辑扁平
- 支持相同排序值下的确定性编号（配合
PARTITION BY或唯一键补全ORDER BY） - 但注意：
ROW_NUMBER()必须走全排序，当ORDER BY字段无索引时，比三层ROWNUM更耗内存和临时表空间 - 如果只是取 Top-N（如前 10 条），
ROWNUM两层嵌套通常更快，因可 early-stop
Oracle 12c+ 推荐用 OFFSET/FETCH，但要注意兼容性
如果你用的是 Oracle 12.1 及以上版本，OFFSET ... ROWS FETCH NEXT ... ROWS ONLY 是最接近 MySQL LIMIT 的写法，也是官方推荐的现代分页语法：
SELECT * FROM employees ORDER BY hire_date DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
- 不需要子查询，不引入额外列名，SQL 更易读、维护成本低
- 执行计划通常更优，Oracle 能更好优化跳过逻辑
- 但老项目若需兼容 11g 或更早版本，硬切
OFFSET/FETCH会报错ORA-00933: SQL command not properly ended - Java 应用中使用 MyBatis 或 JPA 时，框架可能自动适配不同 Oracle 版本，但手写 SQL 仍需显式判断版本分支
真正容易被忽略的点是：无论用哪种方式，ORDER BY 字段**必须有索引支撑**，否则分页性能会随页码增大急剧退化——第 1000 页和第 1 页的响应时间可能差几十倍。别只盯着 SQL 写法，忘了建索引。
