窗口函数适用于保留行结构的聚合（如分组最值+明细共存），不适用于纯聚合统计；必须慎用ORDER BY，避免性能陷阱与NULL异常。
窗口函数能替代子查询但别硬套
窗口函数不是万能的语法糖，它真正有用的地方是「需要在保留原始行结构的同时叠加聚合计算」。比如查每个用户的最新订单时间，同时还要展示该订单的金额、商品名——这时候用 MAX(order_time) OVER (PARTITION BY user_id) 比写关联子查询或 JOIN + GROUP BY 更直观，也避免了因聚合丢失明细字段的问题。
但如果你只是想统计总人数，就别用 COUNT(*) OVER ()，它比单纯 SELECT COUNT(*) 多出不必要的开销，执行计划里会多一次 WindowAgg 节点。
- 适合场景：排名、累计求和、前后行比较（
LAG/LEAD）、分组内最值+原行数据共存 - 不适合场景：纯聚合统计（如总条数、全局平均值）、结果只需一行
- 注意
ORDER BY在OVER子句里的存在与否，会极大影响ROW_NUMBER()和累计类函数的行为
ORDER BY 在 OVER 中漏写可能让 ROW_NUMBER 无意义
ROW_NUMBER()、RANK()、SUM() OVER (ORDER BY ...) 这些函数如果在 OVER 里没写 ORDER BY，结果依赖数据库默认排序（通常是物理存储顺序），不可靠。PostgreSQL 甚至会直接报错；MySQL 8.0+ 虽允许，但同一语句多次执行可能返回不同序号。
例如按用户下单时间排第几笔订单，必须写成：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time)，只写 PARTITION BY user_id 是错的。
- 没有
ORDER BY的ROW_NUMBER()在多数引擎中不保证稳定 -
SUM() OVER (ORDER BY ...)和SUM() OVER ()是两回事：前者是累计和，后者是分组总和广播到每行 - 某些场景下可以用
ORDER BY id代替业务字段，但前提是id真实反映逻辑时序
性能陷阱：窗口函数在大数据量下容易拖慢查询
窗口函数需要对分区内的数据做内存排序或扫描，当 PARTITION BY 字段区分度低（比如只有几个大类），或未建索引时，性能下降明显。特别是 ORDER BY 配合 RANGE BETWEEN 或 ROWS BETWEEN 时，数据库可能无法利用索引加速。
PostgreSQL 的 EXPLAIN ANALYZE 里看到大量 WindowAgg 节点耗时占比高，基本可以确定是瓶颈所在；MySQL 8.0 则要注意 Using filesort 是否出现在窗口相关步骤中。
- 确保
PARTITION BY+ORDER BY字段有联合索引，顺序要匹配（如(user_id, order_time)） - 避免在
WHERE条件前使用窗口函数（即不要在子查询外层才过滤），否则窗口计算会作用于全表 - 考虑用物化视图或临时表预计算高频窗口逻辑，尤其在报表类查询中
NULL 值会让 LAG/LEAD 返回意外结果
LAG(column) 和 LEAD(column) 默认在越界或遇到 NULL 时返回 NULL，但业务上常需要“取上一个非空值”或“用默认值兜底”。比如查上一笔订单金额，但中间有退款单金额为 NULL，直接 LAG(amount) 就断了。
解决方案不是靠窗口函数本身，而是组合表达式：COALESCE(LAG(amount) OVER (PARTITION BY user_id ORDER BY order_time), 0)，或者更复杂的递归逻辑就得换思路了。
-
LAG/LEAD的第三个参数是默认值，可直接写：LAG(amount, 1, 0) OVER (...) - 如果要跳过
NULL取前一个非空，标准 SQL 不支持，需用FIRST_VALUE+IGNORE NULLS（仅 PostgreSQL 14+/Oracle/BigQuery 支持） - MySQL 8.0 不支持
IGNORE NULLS，此时得用变量或自连接模拟，复杂度陡增
窗口函数让逻辑清晰的前提是理解它的执行边界：它不改变行数、不自动去重、不隐式过滤。写完记得看执行计划，尤其当数据量从千级跳到百万级时，原本优雅的写法可能变成性能雷区。
