先问一个看起来很简单的问题：在 Oracle 数据库里，怎么查出表中第一行数据？
这个问题我拿来面试过不少人，也经常在技术社群里看到有人问。有意思的是，能一次答对的不到一半。有的人脱口而出WHERE ROWNUM = 1，有的人上来就写LIMIT 1（明显是写 MySQL 写惯了），还有人直接ORDER BY 1 FETCH FIRST 1 ROW ONLY——语法看着没错，但放到 11g 的生产库上直接报错。
“取第一行”这个需求，做开发的十有八九都写过，但它背后藏着的 Oracle 底层逻辑和那些反直觉的坑，才是真正值得掰开揉碎讲清楚的东西。这篇文章就专门围绕这个问题展开：先说最常见的错误写法为什么错，再讲 ROWNUM 的底层机制，然后给出不同 Oracle 版本下的正确姿势和性能优化思路，最后聊聊随机取行、分组取首行这些进阶场景，以及我实际踩过的两个隐藏比较深的坑。
1. “取第一行”看起来简单，第一个坑就翻车
先说个典型场景。一张订单表orders，里面有几百万行数据，业务方说“给我查一条订单看看字段长什么样”。这种需求其实很常见——不是为了精确取哪一条，而是快速看一眼表里的数据形态。
很多人的第一反应是：
SELECT * FROM orders WHERE ROWNUM = 1;这条 SQL 能跑，也能返回一行数据，但它有一个致命的问题：你根本不知道返回的是哪一行。
这不叫“取第一行”，这叫“取任意一行”——Oracle 从表中读到哪一行，ROWNUM 就给哪一行发号，先被读到的就先拿到 1 号。而“先被读到的”取决于执行计划怎么扫数据。可能是全表扫描的第一行，可能是索引扫描命中的第一行，没有任何业务上的确定性。
另一个更隐蔽的坑是下面这种写法：
SELECT * FROM orders WHERE ROWNUM = 1 ORDER BY create_time DESC;很多人写这段代码的本意是“先按时间倒序排好，再拿第一条”，但实际执行过程完全不是这样。SQL 的语义顺序里，WHERE的过滤发生在ORDER BY排序之前。所以这条 SQL 的真实逻辑是：先随便抓一行，抓住的那行编号为 1，返回，然后排序——排序排的是已经被截断后的那一行，排了等于没排。
这个坑我亲眼见过有人踩。当时一个同事要查“最近创建的一笔订单”，写了类似上面的 SQL，结果返回的是表里最早的一条记录。排查了半天，最后发现根本不是数据问题，是逻辑顺序搞反了。
再往下说，还有一个写法连语法都过不去：
SELECT * FROM orders ORDER BY create_time DESC WHERE ROWNUM <= 1;这个直接在 Oracle 上报 ORA-00933，因为ORDER BY必须放在WHERE之后。有 MySQL 习惯的人特别容易踩这个，毕竟 MySQL 里LIMIT是放在最后的，导致一些朋友误以为 Oracle 也能把条件写后面。
所以你看，光是“取第一行”四个字，就能拆出三种完全不同的需求：
| 需求描述 | 真实意图 | 常见错误 |
|---|---|---|
| 随便拿一条看看 | 取任意一行 | 以为 ROWNUM=1 是确定性的 |
| 把所有行排完序后取第一条 | 取排序后的首行 | WHERE 和 ORDER BY 顺序搞反 |
| 取物理存储上的第一行 | 按块扫描顺序取首行 | 意识到物理顺序不可控 |
这里给新手一个最基本的建议：写“取第一行”之前，先搞清楚你要的是哪种“第一行”。没有排序逻辑的第一行，在 Oracle 里没有任何确定性，依赖它就是给自己埋雷。
2. ROWNUM的伪列机制：为什么必须嵌套子查询才行
要彻底理解上面那些坑，就得从 ROWNUM 的底层机制说起。ROWNUM 是 Oracle 提供的一个伪列，它不是一个真实存储在表中的列，而是查询结果集生成过程中，Oracle 给每一行临时分配的序号。听起来很抽象，打个比方你就懂了。
想象一下你去银行柜台办事。取号机上出的号就是 ROWNUM。但有个特殊规则：只有你已经坐到柜台前的椅子上，叫号器才会给你发号。如果你排在第 2 位，但第一位办完走了、第二位又没来，那叫号器会一直叫 1 号，永远不会叫 2 号。在这个规则下，2 号永远不可能被叫到——除非 1 号先被处理完。
Oracle 的 ROWNUM 就是这套“坐着才发号”的逻辑：
- Oracle 读取结果集第一行，给它标号 ROWNUM = 1，然后检查 WHERE 条件；
- 如果条件不成立，这一行被丢掉，继续读下一行；
- 下一行重新标号 ROWNUM = 1，再检查条件；
- 以此类推。
所以WHERE ROWNUM = 1能返回数据，是因为第一行检查时条件成立。但WHERE ROWNUM = 2永远查不到数据，因为每一行被读到的时候都先被编号为 1，压根等不到编号 2 就被条件过滤掉了。同理，WHERE ROWNUM > 1也永远返回空。
这也就解释了为什么必须先嵌套一层子查询：
SELECT * FROM ( SELECT * FROM orders ORDER BY create_time DESC ) WHERE ROWNUM <= 1;执行顺序是：内层子查询先把所有行排序，生成一个完整的有序结果集；外层查询在这个有序结果集上从头取第一行。这个结果集是“已经排序完的实体”，所以第一行确定就是你要的那条。
注意一个细节：很多人听说嵌套子查询后，会写成这样：
SELECT * FROM ( SELECT * FROM orders WHERE ROWNUM <= 1 ORDER BY create_time DESC );把这个写法和正确写法对比一下，差别就在于ROWNUM 截断发生在子查询内部还是外部。上面这种把 ROWNUM 放在内层子查询里的写法，又是“先取任意一行再排序”，完全失去了嵌套的意义。
理解了这个机制，很多相关的坑都能一眼看出来。比如有的同学问“为什么我加了 ROWNUM <= 1 之后查询变快了？”——因为 Oracle 读到第一行满足条件的行后，就直接停止继续扫描了。这在全表扫描时确实能大幅减少 IO，属于物理上的短路优化。
顺便说一句，ROWNUM 和 ROWID 是两个很容易混淆的概念。ROWID 是行的物理地址，表示这行数据存在哪个文件的哪个块的第几行；ROWNUM 是逻辑序号，表示这行数据在当前查询结果集中的位置。一个对应物理位置，一个对应逻辑顺序，用途完全不同，排查问题时别搞混。
3. 按排序取首行的完整写法与Oracle版本差异
理解了 ROWNUM 机制后，下面把“排序后取首行”的各种写法完整梳理一遍。日常开发里，90% 以上的“取第一行”都是这个意思——按某个业务字段排序，取最前的那条。
3.1 嵌套子查询 + ROWNUM（12c 之前的标准答案）
SELECT * FROM ( SELECT * FROM orders ORDER BY create_time DESC ) WHERE ROWNUM = 1;这是 11g 及更早版本里的标准写法，也是面试里最希望你答出来的那个。注意两个细节：
第一，ROWNUM = 1和ROWNUM <= 1在这里等价，工程上更推荐 <= 1，因为语义上更明确是“取一条”，不容易被误读。
第二，内层子查询里建议加上完整的排序条件。比如按时间排序时，create_time可能出现相同值，这时候最好追加一个唯一键做二级排序：
SELECT * FROM ( SELECT * FROM orders ORDER BY create_time DESC, order_id DESC ) WHERE ROWNUM <= 1;否则 create_time 相同的情况下，返回哪一条又变成不确定的了。
3.2 FETCH FIRST ROW ONLY（12c 及以后的官方推荐）
Oracle 从 12c 开始引入了 ANSI 标准的FETCH FIRST子句，完全就是为了简化这种“取前 N 条”的语义而生的：
SELECT * FROM orders ORDER BY create_time DESC FETCH FIRST 1 ROW ONLY;这个写法和嵌套子查询 + ROWNUM 在大多数场景下性能相当，但可读性好太多——SQL 从前往后读，先明确排序，再明确取几条，非常符合直觉。
如果你需要取前 5 条，写法是FETCH FIRST 5 ROW ONLY。如果要取百分之一，写作FETCH FIRST 1 PERCENT ROW ONLY。如果要取第 2 条到第 3 条，配合 OFFSET：
SELECT * FROM orders ORDER BY create_time DESC OFFSET 1 ROWS FETCH NEXT 2 ROWS ONLY;这就是 Oracle 分页的另一种实现方式。提到分页，做开发的朋友应该马上会联想到ROWNUM三层嵌套分页——那个经典写法其实是本篇文章讨论内容的直接延伸：外层固定总行数，中间层算页码偏移，最内层排序。
这里提醒一句：如果你的生产库还在 11g，FETCH FIRST会直接报 ORA-00933。迁移老项目代码时这个坑很常见，从 12c 代码库往 11g 环境回迁，必须把 FETCH FIRST 改回嵌套子查询写法。
3.3 ROW_NUMBER() 窗口函数
还有一种写法，用分析函数：
SELECT * FROM ( SELECT t.*, ROW_NUMBER() OVER (ORDER BY create_time DESC) rn FROM orders t ) WHERE rn = 1;这个写法的通用性最强，因为ROW_NUMBER()不仅能取整体第一行，还能配合PARTITION BY取分组内的第一行。但代价是它需要对所有行计算序号，然后才能过滤，执行计划里通常多一个 WINDOW SORT 步骤，性能相比 ROWNUM 截断要差。
三种写法放在一起对比一下：
| 写法 | 版本要求 | 可读性 | 性能特征 | 推荐场景 |
|---|---|---|---|---|
| 嵌套子查询 + ROWNUM | 全版本 | 中 | 扫描到首行即停 | 老版本兼容、追求性能 |
| FETCH FIRST | 12c+ | 最好 | 同样支持首行截断 | 新项目首选 |
| ROW_NUMBER() | 全版本 | 中 | 必须全量计算序号 | 分组取首行等复杂场景 |
从我个人的使用习惯来说，12c 以上的新库无脑用 FETCH FIRST，老库用嵌套子查询 + ROWNUM，ROW_NUMBER() 只在需要分组或者需要行号做二次处理时才用。
4. 千万行大表取首行：执行计划与索引提案
前面讲的都是写法层面的问题，实际生产环境里另一个折磨人的问题就是性能。尤其是“几千万行大表”这种场景下取首行，SQL 写对了也可能会跑出让人崩溃的执行时间和 IO 消耗。
先说一个结论：如果只是“随便取一行”，WHERE ROWNUM = 1加上FIRST_ROWS(n)之类的提示，在大表上也能很快返回，因为 Oracle 读到第一行就停了。真正的性能坑集中在“按非索引列排序取首行”这个场景——它必须先把整张表的数据读完、排完序，才能找出第一条。
举个实际例子。某张流水表account_flow有 3000 万行，业务要查“金额最大的一笔流水”，直接写法：
SELECT * FROM ( SELECT * FROM account_flow ORDER BY amount DESC ) WHERE ROWNUM <= 1;我在测试环境跑过，全表扫描加排序，耗时接近 40 秒。这个结果不意外——排序本身要把 3000 万行的 amount 字段全部读出来，放到临时表空间排序，性能瓶颈在 IO 和排序空间上。
优化思路有两个方向。
方向一：把排序字段做成索引。如果amount上有索引，Oracle 可以直接走索引的有序扫描，从头读第一个索引条目就能拿到最大值。虽然还是 INDEX FULL SCAN，但扫描到第一条就停了，不会读完整个索引：
CREATE INDEX idx_account_flow_amount ON account_flow(amount DESC); SELECT * FROM ( SELECT * FROM account_flow ORDER BY amount DESC ) WHERE ROWNUM <= 1;建了降序索引之后，执行计划会变成 INDEX FULL SCAN (MIN/MAX) 类型的路径，执行时间从 40 秒缩短到几十毫秒级别。这里提醒一句，索引建立后别忘了收集统计信息：
EXEC DBMS_STATS.GATHER_INDEX_STATS(USER, 'IDX_ACCOUNT_FLOW_AMOUNT');方向二：如果业务只关心“最大/最小的某个字段值”，而不是完整的一行数据，直接用聚合函数更高效。比如只要最大金额是多少：
SELECT MAX(amount) FROM account_flow;Oracle 对MAX/MIN有专门的优化路径，在普通 B 树索引上做 MIN/MAX 扫描，只需要读两个索引块就能拿到结果，连表数据都不用碰。这在高并发场景下是性价比最高的方案。
再说一个容易忽略的执行计划细节。很多人以为嵌套子查询里写了ORDER BY，子查询就会把全部数据排完序再交给外层。实际上优化器在特定条件下可以做排序消除（sort elimination）——如果排序字段本身就是索引的有序键，优化器会直接把排序操作省掉，改用索引扫描的有序输出。
这也是为什么取首行时，执行计划里到底有没有SORT ORDER BY这一步很重要。用 EXPLAIN PLAN 看一眼：
EXPLAIN PLAN FOR SELECT * FROM ( SELECT * FROM account_flow ORDER BY amount DESC ) WHERE ROWNUM <= 1; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);如果执行计划里出现了SORT ORDER BY，说明优化器老老实实排了序；如果显示的是INDEX FULL SCAN (MIN/MAX)或者直接从索引取数，说明走了优化路径。养成看执行计划的习惯，比死记硬背优化规则靠谱得多。
另外，涉及大表取首行时还要警惕热块竞争。如果业务上高频执行“取最新一条”这类查询，所有人都去抢索引最右端那个叶块，就会产生 buffer busy wait。解决办法通常是反向索引或者减少查询频率，这属于另一层级的优化话题，在这里先提一句，供遇到性能问题的朋友排查时参考。
5. 随机行、分组首行、空表判断几个特殊场景
前面讲的都是“按规则取第一行”，但实际开发中“取第一行”还有几个容易被人问起、又容易写错的变体，我集中放到这一节讲。
5.1 随机取一行
如果业务需求是“从表里随机抽一条”，很多人会写出：
SELECT * FROM orders ORDER BY DBMS_RANDOM.VALUE FETCH FIRST 1 ROW ONLY;这个写法语义上完全没问题，大表上的性能就是另一回事了。DBMS_RANDOM.VALUE会给每一行生成一个随机数，然后全量排序，代价极大。3000 万行的大表跑一次这种查询，几秒钟是少不了的。
大表随机取行的优化思路通常是：先估算表行数，随机一个偏移量，然后从中间位置取。但这是另一个话题了，这里只想表达一个观点：ORDER BY 随机函数的写法只适合小表，大表面试时答这个会被直接追问性能。
5.2 分组取每组的第一行
这是数据分析和报表里非常常见的需求——“每个客户取最新一笔订单”“每个商品分类取价格最低的一款”。很多人会用三层嵌套子查询写，代码又长又难调试。最优雅的做法是前面提到的 ROW_NUMBER()：
SELECT * FROM ( SELECT t.*, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY create_time DESC) rn FROM orders t ) WHERE rn = 1;PARTITION BY把数据按客户分组，组内按时间倒序编号，最后取每组编号为 1 的行。这个写法配合ORDER BY create_time DESC的复合索引（customer_id, create_time DESC）能跑出不错的性能。
顺便对比一下，老开发可能习惯用NOT EXISTS实现同样的需求：
SELECT * FROM orders a WHERE NOT EXISTS ( SELECT 1 FROM orders b WHERE b.customer_id = a.customer_id AND b.create_time > a.create_time );语义是“找一张表里不存在比我更新的订单”——也就是每组最新的一条。这个写法在客户数少、每人订单多的情况下性能可以，但如果客户数量大，关联查询的代价会成倍上涨。我从实测来看，ROW_NUMBER() + 复合索引是更稳妥的选择。
5.3 判断空表和取首行时的边界处理
还有一个经常被忽略的细节：表里没有数据时，“取第一行”会返回什么？
用FETCH FIRST 1 ROW ONLY查询空表，结果集是空的，程序代码里做fetch()会返回NO_DATA_FOUND。如果你是在 PL/SQL 里处理，就要考虑这个异常分支：
BEGIN SELECT create_time INTO v_create_time FROM orders ORDER BY create_time DESC FETCH FIRST 1 ROW ONLY; EXCEPTION WHEN NO_DATA_FOUND THEN v_create_time := NULL; END;这种写法在取最新时间戳时很常用，但它有一个隐患：如果create_time本身允许 NULL，排序后第一条可能恰恰是 NULL。换句话说，你取到了“存在但为 NULL”的时间，跟“表里没有数据”在 PL/SQL 里表现完全不一样。写代码判断空表时，COUNT(*)或者EXISTS更直接：
SELECT COUNT(*) INTO v_cnt FROM orders WHERE ...; IF v_cnt = 0 THEN -- 空表逻辑 END IF;如果你是在存储过程里动态拼 SQL 取首行，记住动态 SQL 和静态 SQL 的 ROWNUM 行为一致，但绑定变量和字面量的执行计划可能不同，这在 11g 的绑定变量窥探（bind peeking）机制下尤其要注意。
6. 我用ROWNUM踩过的两个真实坑与验证方法
理论讲完说实践。最后分享两个我实际踩过的坑，都跟“取第一行/取前几行”有关，希望能帮各位少走弯路。
6.1 坑一：PL/SQL 游标里 ROWNUM 放错了层
当时要写一个报表存储过程，逻辑是“从子表里取最近三条记录，然后循环处理”。我一开始写的代码是：
FOR rec IN ( SELECT * FROM child_table WHERE parent_id = p_parent_id AND ROWNUM <= 3 ORDER BY create_time DESC ) LOOP ... END LOOP;一眼看过去觉得没问题，又是过滤又是排序。但实际跑出来的结果完全不对——取到的三条根本不是最新的三条。原因就是前面讲的那个机制：WHERE ROWNUM <= 3在ORDER BY之前执行，先把物理扫描的前三条抓走了，然后才排序。
正确写法还是那招——嵌套子查询：
FOR rec IN ( SELECT * FROM ( SELECT * FROM child_table WHERE parent_id = p_parent_id ORDER BY create_time DESC ) WHERE ROWNUM <= 3 ) LOOP ... END LOOP;这个坑的问题在于它不像语法报错那样直接暴露，而是数据结果不对。数据量的变化也可能让问题时隐时现——小表扫描顺序碰巧和排序一致时，结果是对的；数据一多，物理顺序变了，就出现偶发错误。这类“偶尔错、偶尔对”的问题在排查时最难定位。
6.2 坑二：ORDER BY 的列没进 SELECT 列表，排序被优化器阴了一把
第二个坑更隐蔽。当时有个分页查询，外层是 ROWNUM 控制页大小，内层子查询排序。为了“精简结果集”，内层 SELECT 只选了业务要展示的字段，排序字段在子查询里没出现在 SELECT 列表中：
SELECT * FROM ( SELECT order_id, order_amount, status FROM orders ORDER BY create_time DESC ) WHERE ROWNUM <= 20;Oracle 文档里明确说明：ORDER BY的列需要出现在 SELECT 列表中，否则不保证排序结果。但实际执行时它也不一定报错——优化器可能会自行处理，在某些执行路径下排序结果符合预期，换了一种执行计划后结果就变了。
我在 19c 上测试，这种写法在某些索引组合下会出现返回行乱序的情况，排查了很久才定位到是排序字段被优化器“优化”掉了。解决办法有两个：一是把create_time也放进子查询的 SELECT 列表；二是设计复合索引(create_time DESC, order_id)让排序完全走索引。
6.3 验证写法正确性的通用方法
最后分享一个通用的验证思路。不管用哪种写法，写完后先问三个问题：
- SQL 的语义执行顺序是什么？WHERE 过滤、排序、行数截断，哪个先哪个后？Oracle 里 WHERE 一定在 ORDER BY 之前，窗口函数在 ORDER BY 之后，别搞反。
- 执行计划里有没有多余的全表排序？EXPLAIN PLAN 看有没有 SORT ORDER BY，有就说明排序躲不掉，如果业务能接受没排序的“第一行”，直接 ROWNUM=1 完事，性能差着两个数量级。
- 结果是不是确定性的？连续跑三次，如果三次返回一样的行才算稳定。如果业务对“第一行”的定义模糊，干脆把结果设为任意行，并让产品接受这个现实。
这三个问题想明白，基本上“取第一行”相关的 SQL 就不会再翻车了。
最后再顺手分享一个小笔记：Oracle 的OFFSET ... FETCH语法其实从 12c 开始一直沿用到现在，如果你开发环境是 21c 或 23ai，可以放心用；如果你要兼容 11g 的老生产环境，嵌套子查询 + ROWNUM 才是那块压舱石。碰到取首行需求，先问清楚业务意图，再选对应的 SQL 形态，这样写出来的查询既高效又经得起推敲。
