row_number()不能在where或having中直接引用，因其属于select阶段计算结果，而where和having执行早于select；必须通过子查询或cte封装后在外层过滤。
WHERE 和 HAVING 都不能直接引用 ROW_NUMBER()
ROW_NUMBER() 是窗口函数，它在 SQL 逻辑执行顺序中属于 SELECT 阶段的计算结果，而 WHERE 和 HAVING 都在 SELECT 之前执行（WHERE 在 FROM/JOIN 后、GROUP BY 前；HAVING 在 GROUP BY 和聚合之后、但仍在 SELECT 计算行号之前）。所以无论是 WHERE rn > 1 还是 HAVING rn = 1，数据库在解析时根本还没生成 rn 这个列——报错信息如 column "rn" does not exist 就是这个原因。
这不是语法写错，是执行阶段硬性限制。MySQL、PostgreSQL、SQL Server、Oracle 全部如此，和版本无关（哪怕 MySQL 8.0+ 支持窗口函数，也不改变执行顺序）。
ROW_NUMBER() 必须用子查询或 CTE 封装后才能过滤
唯一通用、跨数据库兼容的做法，是把带 ROW_NUMBER() 的查询作为中间结果，再在外层加 WHERE：
-
使用 CTE 更清晰，适合多步逻辑：
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM employees ) SELECT id, name, dept_id, salary FROM ranked WHERE rn
-
使用派生表（子查询）更轻量，适合单次使用：
SELECT id, name, dept_id, salary FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM employees ) t WHERE rn
注意：别在 OVER() 里硬塞条件试图“绕过”，比如 ROW_NUMBER() OVER (ORDER BY CASE WHEN status = 'active' THEN salary END DESC) ——这只会让排序混乱，不解决过滤问题。
为什么 QUALIFY 也不能用于 ROW_NUMBER() 过滤？
QUALIFY 确实能直接写 ROW_NUMBER() OVER (...) = 1，但它不是标准 SQL，且不支持所有场景：
- BigQuery / Snowflake / DuckDB / MaxCompute 支持，语法简洁
- MySQL（截至 2026 年最新版）、PostgreSQL（原生不支持）、SQL Server（不支持）均不可用
-
QUALIFY要求其表达式中必须包含至少一个窗口函数，不能只写普通列条件 - 它仍受窗口定义约束：比如
PARTITION BY范围不对，QUALIFY结果就会错
所以依赖 QUALIFY 会牺牲可移植性，而子查询/CTE 方案在任何支持窗口函数的数据库（MySQL 8.0+、PostgreSQL 9.4+、SQL Server 2012+）上都可靠。
容易被忽略的排序稳定性问题
ROW_NUMBER() 的输出顺序完全取决于 OVER() 中的 ORDER BY，而不是最终查询的 ORDER BY。如果 ORDER BY 列存在重复值（比如多个员工 salary 相同），不同执行可能分配不同行号——尤其在无索引或并发环境下。
解决方案很简单：在 ORDER BY 末尾补一个唯一列，例如：
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC, id)
这样即使 salary 相同，id 也能打破并列，保证每次执行结果一致。很多线上分页 bug，根源就在这里。
