qualify 必须紧接 select 后、order by 前，且表达式中必须包含窗口函数；仅能引用已定义的窗口别名，不可用普通字段或聚合函数；row_number() 配合 qualify 是分组 top-n 最稳方案。

QUALIFY 能直接过滤窗口函数结果，但必须用对位置、写对表达式，否则报错或逻辑错。

QUALIFY 必须紧接在 SELECT 之后、ORDER BY 之前

它不是可随意放置的过滤子句，执行顺序严格固定：WINDOW 计算完成 → QUALIFY 判断 → 投影 → ORDER BY → LIMIT。写错位置会直接报语法错误。

• 合法位置：SELECT ... FROM ... WHERE ... QUALIFY ... ORDER BY ...
• 非法位置：QUALIFY 放在 WHERE 前、GROUP BY 后、或 ORDER BY 之后——全部不通过
• 如果用了 WINDOW 子句（显式命名窗口），QUALIFY 只能引用该子句中已定义的别名，不能现场重写窗口表达式（部分引擎如 Databricks 会拒斥）

QUALIFY 表达式里必须含窗口函数

这是硬性语法要求，不是建议。引擎会检查布尔表达式是否至少包含一个窗口函数调用，否则报错 No window function in QUALIFY clause。

• 允许：QUALIFY ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) = 1
• 允许：QUALIFY rn = 1（前提是 rn 已在 SELECT 列表中定义为窗口别名）
• 禁止：QUALIFY dept = 'sales'（这是原始字段，该用 WHERE）
• 禁止：QUALIFY COUNT(*) > 10（聚合函数不允许出现在 QUALIFY 中）

分组 Top-N 场景下，ROW_NUMBER() + QUALIFY 最稳

要取“每个部门薪资前 3 的员工”，用 ROW_NUMBER() 配合 PARTITION BY 是唯一能保证结果行数可控的方式。

• ROW_NUMBER() 编号严格递增、无并列，QUALIFY rn BETWEEN 1 AND 3 精准返回每组最多 3 行
• RANK() 有并列会跳号，QUALIFY rank BETWEEN 1 AND 3 可能漏掉实际第 3 名（比如并列第 2 名后直接是第 4 名）
• DENSE_RANK() 不跳号但可能超量，QUALIFY dense_rank 可能返回 5 行甚至更多，适合“保留并列”场景，但不是严格 Top 3
• ORDER BY 必须明确且稳定：相同 salary 时，务必加次级排序（如 ORDER BY salary DESC, employee_id ASC），否则 ROW_NUMBER() 结果不可复现

不支持 QUALIFY 的引擎只能硬套子查询

MySQL 8.0+、PostgreSQL 13 及更早版本、SQL Server 全系均不支持 QUALIFY。遇到 syntax error at or near "QUALIFY" 不是写错了，是引擎不认。

• 通用解法：用派生表封装窗口计算，外层 WHERE 过滤
  SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts) AS rn FROM events) t WHERE rn = 1
• 可读性更好：用 CTE 分步写
  WITH ranked AS (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t) SELECT * FROM ranked WHERE rn = 1
• 注意括号匹配和别名作用域：子查询里定义的 rn，外层才能引用；漏写别名或拼错名字会报 column "rn" does not exist
• BigQuery / Snowflake / Databricks / MaxCompute / DuckDB / Oracle 26ai 支持，但细节有差异：BigQuery 允许 QUALIFY 内联窗口函数，Snowflake 和 Databricks 要求显式别名

真正容易被忽略的是：QUALIFY 的语义绑定在窗口计算的“逻辑行集”上，它不感知原始表结构，只认当前 SELECT 阶段输出的列和窗口值。一旦误把业务条件塞进 QUALIFY（比如用它过滤时间范围），不仅性能差，还可能因执行顺序导致结果偏差——这种错误不会报错，但数据就 quietly 错了。