添加FETCH FIRST ROW ONLY子句后查询性能大幅提升的原因解析

核心原因：查询优化器执行计划的改变 #

添加fetch first 10000000 row only后，数据库优化器判断不需要处理全量数据（即便设置的行数远大于实际返回的29000行），会切换到更高效的执行策略，而非原本为全量数据设计的计划。具体拆解如下：

1. 规避昂贵的全量排序操作 #

如果你的薪资查询包含ORDER BY、薪资计算常用的窗口函数（如ROW_NUMBER()、RANK()），或分组聚合需排序的步骤，原始计划可能会执行磁盘临时表全量排序，IO与CPU开销极高。添加fetch first后，优化器会采用流式排序或提前终止排序流程，大幅降低资源消耗。

2. 提前终止关联/扫描流程 #

多表关联的复杂查询中，原始计划通常会完成所有表的关联、过滤后再返回数据。而fetch first会让优化器调整执行顺序：在扫描或关联过程中，一旦收集到足够满足条件的行数，就立即终止后续的扫描、关联操作，避免处理不必要的数据。

3. 切换更轻量的访问路径 #

原本为全量数据选择的全表扫描+哈希关联，可能被替换为索引扫描+嵌套循环关联——后者在仅需获取部分数据时，无需构建庞大的哈希表，性能提升显著。

4. 避免不必要的物化操作 #

若查询包含子查询、CTE（公共表表达式），原始计划可能会将这些结果物化到临时表中。添加fetch first后，优化器会尝试将子查询/CTE与主查询合并，规避物化带来的磁盘IO和数据拷贝开销。

补充说明 #

这里设置的10000000远大于实际返回行数，但优化器不会因数值大忽略该限制，仅会判断“无需处理全部数据”，进而切换高效执行计划。这类现象在DB2、PostgreSQL等支持fetch first/limit语法的数据库中均可能出现。

内容的提问来源于stack exchange，提问作者Arash