WHERE中直接使用ROW_NUMBER()必然报错，因其在SQL执行顺序（FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY）中晚于WHERE，该阶段窗口函数尚未计算，列根本不存在；必须用带表别名的子查询或CTE先固化结果，且OVER中PARTITION BY和ORDER BY缺一不可。
WHERE 里写 ROW_NUMBER() 必然报错，不是语法限制，而是 SQL 执行阶段根本还没算出这个值。
WHERE 阶段窗口函数压根不存在
SQL 按固定逻辑顺序执行：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。窗口函数（包括 ROW_NUMBER()）只在 SELECT 阶段才开始计算，而 WHERE 在此之前就已完成——此时连分区、排序、编号这些动作都还没发生，数据库连“rn 列在哪”都不知道。
常见错误现象：
- PostgreSQL 报
window functions are not allowed in WHERE - MySQL 报
Unknown column 'rn'（哪怕你写了AS rn） - SQL Server 报
Invalid use of window function
必须用子查询或 CTE 先固化结果
把 ROW_NUMBER() 放进子查询或 WITH 里，在内层完成编号并起别名（如 AS rn），外层再用 WHERE rn = 1 过滤。这是唯一跨数据库兼容的解法。
关键注意点：
- 子查询必须带表别名（如
) t），否则 MySQL 直接报Every derived table must have its own alias -
OVER中的PARTITION BY和ORDER BY缺一不可：漏掉PARTITION BY就变成全表编号；漏掉ORDER BY会导致编号顺序依赖物理存储，结果不可复现 - CTE 更适合多步逻辑（比如先
RANK()再算累计占比），但别在 CTE 里写SELECT *，只选真正需要的字段，减少内存开销
别信 QUALIFY，它不解决根本问题
虽然 BigQuery、Snowflake、MySQL 8.0+ 支持 QUALIFY（如 QUALIFY ROW_NUMBER() OVER (...) = 1），但它只是语法糖，底层仍等价于自动套了一层子查询。而且 QUALIFY 不解决并列时的取数歧义：ROW_NUMBER() 才能保证“严格取第 N 条”，RANK() 或 DENSE_RANK() 在值相同时可能返回多条或少于 N 条。
最容易被忽略的其实是 ORDER BY 的稳定性
哪怕语法跑通了，如果 ORDER BY 字段没索引、允许 NULL、或精度不足（比如大量 created_at 都是秒级），ROW_NUMBER() 分配就会抖动——翻页时同一条记录可能出现在两页，高并发去重时可能漏掉最新消息。真正可靠的排序必须有确定性，例如 ORDER BY ingest_timestamp, id，而不是只靠业务时间字段。
