QUALIFY能直接过滤窗口函数结果，因它在SELECT后、ORDER BY前执行，专为对窗口函数输出做WHERE式过滤设计；支持ROW_NUMBER()等且可结合PARTITION BY实现分组Top N。

QUALIFY 子句为什么能直接过滤窗口函数结果

因为 QUALIFY 是 SQL 中唯一允许在逻辑上「对窗口函数输出做 WHERE 式过滤」的语法，它在 SELECT 之后、ORDER BY 之前执行，天然避开「不能在 WHERE 中用窗口函数」的限制。不写 QUALIFY 就得嵌套子查询或 CTE，多一层括号、多一次扫描。

• BigQuery、Snowflake、Databricks SQL 原生支持；PostgreSQL 14+ 通过 WITH TIES 或子查询模拟，但无原生 QUALIFY
• MySQL 8.0+ 不支持 QUALIFY，必须用派生表（SELECT * FROM (SELECT ..., ROW_NUMBER() OVER(...) rn) t WHERE rn BETWEEN 11 AND 20）
• QUALIFY 内部可直接写 ROW_NUMBER()、RANK()、DENSE_RANK() 等，无需提前定义别名

提取第 11 到 20 名：用 ROW_NUMBER() + QUALIFY 最稳

当需要严格按顺序取“跳过前 10 的下 10 条”，ROW_NUMBER() 是唯一可靠选择——它不并列、不跳号，保证结果集大小可控。用 RANK() 或 DENSE_RANK() 在有并列时可能返回 12 行甚至 8 行，不是“第 11–20 名”而是“排名 ≤20 且 >10 的所有行”。

• 正确写法：SELECT user_id, score FROM scores QUALIFY ROW_NUMBER() OVER (ORDER BY score DESC) BETWEEN 11 AND 20
• 错误写法：QUALIFY RANK() OVER (...) BETWEEN 11 AND 20 —— 若第 10 名有 3 人并列，则第 11 名实际是第 13 行，中间空号导致漏数据
• 注意 ORDER BY 必须明确，否则 ROW_NUMBER() 结果不确定；如有相同分数，建议加次级排序（如 ORDER BY score DESC, user_id ASC）保稳定

分组内取 Top N：QUALIFY 配合 PARTITION BY 很自然

要查“每个部门薪资前 3 的员工”，不用写三层嵌套（GROUP BY → 窗口 → 外层过滤），QUALIFY 直接把逻辑压进一行。关键是 PARTITION BY 和 QUALIFY 的作用域完全对齐——每个分区独立编号，QUALIFY 对每个分区的结果分别判断。

• 示例：SELECT dept, name, salary FROM employees QUALIFY ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)
• 若想保留并列（如“薪资 ≥ 第 3 名者都算”），改用 DENSE_RANK() ，但需接受结果数可能 >3
• 性能提示：窗口函数本身已触发排序，QUALIFY 过滤不增加额外计算，但 PARTITION BY 字段若有高基数（如百万级 user_id），可能影响内存占用

常见报错和绕过方式：当 QUALIFY 不可用时

遇到 ERROR: syntax error at or near "QUALIFY"，不是语法写错，是引擎不支持。别硬扛，换等价结构，核心就两条：要么升版本，要么套一层子查询。

• Snowflake 用户开 ENABLE_QUALIFY 参数（需 ACCOUNTADMIN 权限）可临时启用，但生产环境不推荐依赖实验性开关
• PostgreSQL：用 LIMIT/OFFSET 做分页更高效，但仅适用于全局排序分页；分组 Top N 必须用 LATERAL JOIN 或子查询
• 最通用 fallback：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (...) rn FROM t) t2 WHERE rn BETWEEN 11 AND 20 —— 注意外层不能选 * 如果内层含大字段（如 JSON、TEXT），会拖慢传输

真正容易被忽略的是排序稳定性：没写 ORDER BY 子句的窗口函数，在分布式引擎（如 BigQuery）中可能每次运行结果不同，哪怕数据没变。别省那几个字符。