窗口函数不能直接用在 WHERE、GROUP BY 或 HA VING 里，这个坑几乎每个写 SQL 的都踩过。必须先把窗口计算结果放到子查询或 CTE 中，再在外层引用，否则就会报错。
先说最典型的错误场景：在 WHERE 里直接写 ROW_NUMBER()。比如 SELECT * FROM t WHERE ROW_NUMBER() OVER (PARTITION BY x ORDER BY y) —— 这行代码要么触发 Unknown column，要么提示 Window function is not allowed in this context。原因很简单：SQL 的执行顺序里，WHERE 的优先级高于 SELECT（包括窗口函数），所以系统根本不知道窗口函数在说什么。
- 正确做法：先用子查询或 CTE 算出编号，外层再
WHERE rn - 别忘了
PARTITION BY和显式的ORDER BY，否则编号毫无意义 - 如果排序字段有重复值（比如多个订单时间相同），加一个唯一字段如
id来保序：ORDER BY created_at DESC, id DESC
再来看 GROUP BY 的陷阱。想按“与前一日差值是否为正”来分组？GROUP BY LAG(amount) OVER (ORDER BY date) 这样的写法是绝对非法的。窗口函数的输出结果不能直接作为分组键，必须先把结果物化出来。
- 必须先用 CTE 或子查询生成
prev_amount字段，再在外层的GROUP BY引用它 - MySQL 8.0+ 支持在派生表里用
LAG，但如果外层又加了GROUP BY，一定要确保排序上下文不丢失 - PostgreSQL 虽然更宽松，但如果子查询用了
ORDER BY而外层没重排，LAG的结果很可能错位
嵌套子查询里的 ORDER BY 也是个容易混淆的点。子查询里写 ORDER BY date 只影响结果集的顺序，对内层的 ROW_NUMBER() OVER (ORDER BY ...) 完全没有作用。窗口函数的排序必须显式写在 OVER 子句里。
ROW_NUMBER() OVER (ORDER BY date)和子查询的ORDER BY date是两码事，不能互相替代- 如果窗口函数里忘了写
ORDER BY，编号结果就没法预测了，尤其在 MySQL 中，不同次执行结果可能完全不同 - 日期字段是
VARCHAR类型时，隐式转换会导致排序错乱，务必确认类型一致
说到多层窗口函数，CTE 比嵌套子查询可靠得多。当需要同时用 ROW_NUMBER() 和 LAG() 再做聚合时，CTE 能清晰隔离每一步逻辑，还能避免优化器多次扫描。
- MySQL 8.0 的 CTE 默认可以物化，比老式的
FROM (SELECT ...) t更稳定 - 不要在一个 SELECT 里堆多个不同
PARTITION BY和不同ORDER BY的窗口函数——PostgreSQL 和 SQL Server 很可能会分别排序，性能直接翻倍 - 如果只是要总行数这类全局指标，
COUNT(*) OVER ()看似方便，但空OVER()在 PostgreSQL 中会触发全表排序，效率不如先查COUNT(*)再 JOIN
说到底，窗口函数的执行时机晚于 WHERE 但早于外层 ORDER BY，这意味着它的输入数据已经过过滤，但输出列不能反向影响过滤条件。所有依赖窗口结果的处理逻辑，都必须放在第二层查询里——这一点，才是最容易忽略的关键。
