窗口函数需先写PARTITION BY再ORDER BY，且ORDER BY在多数数据库中不可省略；执行阶段在GROUP BY后、HAVING前，不能引用未SELECT或GROUP BY的列；MySQL 5.7不支持，须升级至8.0+。
窗口函数怎么写才不报错：PARTITION BY 和 ORDER BY 的位置陷阱
很多人一写 ROW_NUMBER() 或 SUM() OVER() 就遇到 Window function is missing ORDER BY 或 GROUP BY clause is required，根本原因不是语法写错，而是没理解窗口函数的执行阶段——它在 GROUP BY 之后、HAVING 之前运行，但又不能依赖未出现在 SELECT 或 GROUP BY 中的列做排序。
-
PARTITION BY可以省略，但一旦写了ORDER BY，绝大多数数据库（PostgreSQL、SQL Server、MySQL 8.0+）就强制要求它必须存在；SQLite 是个例外，允许只ORDER BY不PARTITION BY - 如果目标是“每组内按时间倒序编号”，别写成
ORDER BY created_at DESC后直接套WHERE rn = 1——这会过滤掉窗口计算前的原始行，得用子查询或 CTE 包一层 - MySQL 5.7 不支持窗口函数，强行用会报
FUNCTION xxx does not exist；升级前先查SELECT VERSION()
轻量报表常用模式：累计求和、同比环比、Top N 每组取一
报表里最常卡壳的不是逻辑，是“既要分组又要跨行计算”时不知道该用哪个函数。比如日销售额累计，用 SUM(sales) OVER (ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) 最稳；但若想算“比上周同期涨了多少”，就得先用 LAG(sales, 7) OVER (ORDER BY date) 拿上周值，再手动相减。
-
LAG()和LEAD()的第二个参数是偏移量，默认为 1；第三个参数是空值替代值，不填就是NULL，做除法前务必COALESCE(..., 0)防崩 - 要取每个品类销量 Top 3，别用
GROUP BY category HAVING COUNT(*) ——那是分组计数，不是排序取前几；正确姿势是 <code>ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC)+ 外层WHERE rn - Oracle 和 PostgreSQL 支持
PERCENT_RANK()，MySQL 目前还不行；想兼容多库就别依赖这个函数
性能雷区：ORDER BY 走不走索引？窗口函数会不会拖垮查询
窗口函数本身不产生临时表，但它的 ORDER BY 子句会触发排序操作。如果 OVER 里的排序字段没索引，单次查询可能从毫秒变秒级——尤其当基础数据超百万行时。
- 检查执行计划：PostgreSQL 看
WindowAgg下有没有Sort节点；MySQL 8.0+ 用EXPLAIN FORMAT=TREE，留意是否出现window_function+filesort - 复合索引要匹配
PARTITION BY在前、ORDER BY在后，例如(category, sale_date)才能加速OVER (PARTITION BY category ORDER BY sale_date) - 避免在窗口函数里嵌套复杂表达式，比如
UPPER(name)或DATE(created_at)做ORDER BY——索引失效，且计算开销翻倍
兼容性细节：不同数据库对 RANGE 和 ROWS 的处理差异
ROWS BETWEEN ... AND ... 是安全的，所有支持窗口函数的数据库都认；但 RANGE 就麻烦了——它按值范围而非物理行定位，PostgreSQL 和 Oracle 行为一致，MySQL 却只支持 RANGE 用于 UNBOUNDED PRECEDING 场景，其他情况直接报错。
- 想算“过去7天滚动销售额”，别写
RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW（PostgreSQL 可用，MySQL 不行），老实用ROWS BETWEEN 6 PRECEDING AND CURRENT ROW+ 日期字段已排序的前提 - SQL Server 默认用
ROWS，不显式声明也行；但 PostgreSQL 和 MySQL 必须写明，否则默认是RANGE，容易导致结果意外重复或遗漏 - 如果业务逻辑强依赖值语义（比如“价格≤当前行的所有行求和”），优先测试 PostgreSQL，再考虑降级方案
窗口函数不是银弹，特别是当你要把多个层级的聚合（比如“每个区域的 Top 3 品类中，每个品类的月度趋势”）塞进一个查询时，嵌套 CTE 比硬塞进一层 OVER 更易读、更可控。另外，别忘了——很多 BI 工具导出的 SQL 会自动加 LIMIT，而窗口函数的计算发生在 LIMIT 之前，结果可能和预想的不一致。
