QUALIFY 直接作用于窗口计算结果，跳过子查询物化，是执行逻辑上的关键补位；它位于 WINDOW 子句后、ORDER BY 前，仅能引用已定义的窗口别名，不支持所有引擎但大幅简化分组过滤逻辑。
QUALIFY 直接作用于窗口计算结果，跳过子查询物化
它不是语法糖，而是执行逻辑上的关键补位：窗口函数必须在 SELECT 阶段完成计算，但 WHERE 在此之前就已结束，所以你永远不能写 WHERE ROW_NUMBER() OVER (...) = 1——会报错 Window function not allowed in WHERE clause。传统做法只能用子查询或 CTE 把带窗口的结果先存下来，再过滤。而 QUALIFY 插在窗口计算之后、投影之前，不生成中间表，也不复制数据。
- 大表上物化开销可能占总耗时 40% 以上，尤其当
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts)产出百万行时 -
QUALIFY过滤发生在内存中逐行判断，不触发额外 shuffle（Snowflake 中常被优化器下推到扫描层） - 不支持
QUALIFY的引擎（如 MySQL 8.0+、PostgreSQL 14 以下）必须硬套子查询，代码多 3–5 行，括号易错
QUALIFY 的语法位置和依赖关系很严格
它必须出现在 WINDOW 子句之后、ORDER BY 之前，且只能引用当前 SELECT 列表中已定义的窗口别名，或直接内联窗口表达式。它不“创造”列，只“认”列。
- 合法：
SELECT dept, salary, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn FROM employees QUALIFY rn - 非法：
QUALIFY ROW_NUMBER() OVER (...) （没在SELECT里定义，部分引擎如 Databricks 会报错） - 非法：
QUALIFY salary > 10000（这是原始字段，该用WHERE） - 注意：BigQuery 允许直接写窗口函数在
QUALIFY中，Snowflake 和 Databricks 要求显式别名
分组 Top-N 场景下，QUALIFY + PARTITION BY 天然对齐
每个分区的窗口编号是独立生成的，QUALIFY 对每个分区的结果分别判断，逻辑干净，不用担心跨分组污染或排序错位。
- 取每个部门薪资前 3：用
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)最稳，结果行数严格可控 - 想保留并列（如“所有薪资 ≥ 第 3 名者”）：换
DENSE_RANK()，但要接受结果数可能 >3 - 错误示范：
QUALIFY RANK() OVER (PARTITION BY dept ORDER BY salary DESC) BETWEEN 1 AND 3——若有并列第 2 名，第 3 名会被跳过 - 性能提示：高基数
PARTITION BY字段（如千万级user_id）可能撑高内存，建议加CLUSTER BY或预过滤
引擎兼容性差异比想象中更实际
不是“支持或不支持”二值判断，而是功能粒度不同。同一关键词，在不同系统里能写什么、不能写什么，直接影响你能否安全迁移 SQL。
- Snowflake：全支持，包括
LAG()、AVG() OVER ()等非排名类窗口函数 +QUALIFY - Databricks：Spark SQL 3.3+ 支持，但禁止
QUALIFY中出现NOW()、RAND()等非确定性函数 - BigQuery：原生支持，语法最宽松，允许
QUALIFY SUM(x) OVER () > 100这类聚合型窗口过滤 - PostgreSQL：无原生
QUALIFY，得靠WITH TIES或子查询模拟，ROW_NUMBER()+LIMIT仅适用于全局 Top-N，不适用于分组
真正容易被忽略的是：QUALIFY 不改变窗口函数本身的计算逻辑，它只是把“算完就筛”这件事从用户代码里收走，交给执行引擎统一调度。一旦你习惯用它，再回去写三层嵌套子查询，会明显感到逻辑断层和调试成本上升——不是因为不会写，而是因为语义不该这么绕。
