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）中可能每次运行结果不同，哪怕数据没变。别省那几个字符。
