qualify比嵌套查询更高效，因其在窗口计算完成后直接过滤，跳过物化中间结果，避免重复扫描与排序，执行计划更扁平，且强制表达式含窗口函数以明确数据依赖。
QUALIFY 子句在支持它的引擎（如 Snowflake、Databricks、BigQuery）中，确实比等价的嵌套查询更高效——核心原因是它跳过了物化中间结果这一步，且执行计划更扁平。
QUALIFY 直接作用于窗口计算后的逻辑行集
窗口函数（如 ROW_NUMBER()、RANK()）必须在所有 WHERE、GROUP BY 之后执行，但又必须在 SELECT 投影之前完成。传统写法被迫用子查询“抬升”窗口结果，导致数据库必须把带序号的整张中间表先算出来、存进临时空间，再过滤。而 QUALIFY 是在这个逻辑阶段直接介入：窗口值一生成，立刻判断是否满足条件，不存、不复制、不重排。
-
QUALIFY执行时机 = 窗口计算完成 → 过滤 → 投影，三步紧耦合 - 嵌套写法执行时机 = 外层
SELECT→ 内层SELECT（含窗口）→ 物化中间结果 → 外层WHERE再扫描一遍 - 大表上物化开销可能占总耗时 40% 以上，尤其当
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts)产生百万级中间行时
嵌套查询容易触发非最优执行计划
多数优化器对多层派生表（FROM (SELECT ...) AS t）的统计信息推断能力较弱，尤其当内层含窗口函数时，外层 WHERE 条件无法下推，导致扫描行数远超必要量。
- 例如：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY ts) rn FROM events) WHERE rn = 1，优化器常无法识别rn = 1实际只需每个分区首行，仍按全表扫描估算 - 而
SELECT * FROM events QUALIFY ROW_NUMBER() OVER (PARTITION BY id ORDER BY ts) = 1，引擎明确知道这是“每组取 Top 1”，可启用专用算子（如 Top-N per group） - 某些场景下，嵌套写法会额外引入 Sort 或 Spill-to-disk，
QUALIFY版本则全程流式处理
语法限制暴露真实依赖，避免隐式错误
QUALIFY 强制要求其表达式里至少有一个窗口函数，这反而是优势：它让 SQL 的数据依赖关系一目了然，不会像嵌套查询那样掩盖“这个 WHERE 其实依赖未投影的计算列”这类逻辑断裂。
- 写错时立刻报错：
QUALIFY id > 100会提示 “No window function in QUALIFY clause”，而不是静默返回空结果或错误数据 - 嵌套查询中若误把
WHERE放在内层（SELECT * FROM (SELECT ..., ROW_NUMBER()... FROM t WHERE ...)），可能提前过滤掉影响分组的数据，结果出错却难定位 - 团队协作时，
QUALIFY的意图比三层嵌套更易被快速理解，减少 review 漏洞
真正要注意的是：MySQL、PostgreSQL（截至 2026 年中）、SQL Server 仍不支持 QUALIFY，强行迁移需回退到 CTE 或嵌套；另外，QUALIFY 不能替代 HAVING（它不作用于聚合结果），也不能和 ORDER BY 同时控制最终排序——这些边界容易被忽略。
