报错主因是混用普通聚合与窗口函数或错误使用group by；over子句必须单独使用，不可与group by共存，且partition by字段须为select中已存在列，order by仅影响排序敏感函数。
OVER子句本身不报错，报错是因为你把它塞进了不兼容的上下文里——比如和GROUP BY混用，或者在SELECT里裸写SUM()却忘了加OVER。
为什么写了SUM() OVER()还报“窗口函数必须有 OVER 子句”
这个错误通常不是OVER写错了，而是SQL引擎在解析时发现你同时用了普通聚合（比如没带OVER的SUM）和窗口函数，它无法决定该按哪套规则执行。
- 错误写法：
SELECT customer_id, SUM(amount), SUM(amount) OVER(PARTITION BY customer_id) FROM orders——SUM(amount)是普通聚合，SUM(amount) OVER()是窗口函数，二者不能共存 - 正确做法：要么全用窗口函数（
SUM(amount) OVER(PARTITION BY customer_id)），要么全用GROUP BY（GROUP BY customer_id+SUM(amount)），不能混搭 - 注意：
OVER()空括号合法，表示全表范围；但字段必须出现在SELECT列表中，不能只出现在OVER里，比如SUM(amount) OVER(PARTITION BY category)要求category得是SELECT里已有的列或表达式
PARTITION BY字段必须真实存在，不能是别名或计算列
很多人想先算一个分类标签再分区，比如UPPER(name) AS name_upper，然后写OVER(PARTITION BY name_upper)——这会直接报错。
-
PARTITION BY只能引用FROM子句产出的原始列、或其确定性表达式（如customer_id % 10），不能引用SELECT列表中的别名 - 如果真要按计算结果分区，得把逻辑提前到子查询或CTE里，例如：
WITH t AS (SELECT *, UPPER(name) AS name_upper FROM users) SELECT *, SUM(val) OVER(PARTITION BY name_upper) FROM t - 高基数字段（如订单ID）做PARTITION BY可能比JOIN还慢，尤其没索引时；优先选低基数、高频过滤的字段，比如
status或region
ORDER BY在OVER里只对部分函数生效
ORDER BY写在OVER()里，不是为了给最终结果排序，而是为某些窗口函数提供计算顺序依据。
- 对
ROW_NUMBER()、RANK()、AVG() OVER(ORDER BY ...)这类函数是必需的，否则行为未定义 - 对
SUM() OVER(PARTITION BY x)这种纯分组聚合，ORDER BY完全没作用，加了白费性能，还可能误导后续维护者 - 如果用了
ROWS BETWEEN或RANGE BETWEEN，ORDER BY就变成强制项；RANGE依赖值连续性，遇到重复值或时间间隔不均容易出意外，ROWS更可控
MySQL 8.0+ 和 SQL Server 支持，但SQLite和旧版MySQL不行
不是所有数据库都认OVER，部署前务必确认版本和引擎能力。
- MySQL：仅8.0+支持，5.7及之前版本会直接报语法错误；检查方式：
SELECT VERSION() - PostgreSQL：8.4+支持，但
RANGE帧语法在9.0+才稳定，早期版本慎用RANGE BETWEEN - SQL Server：2005+支持，但
STRING_AGG() OVER()等新函数需2017+；存储过程中直接用没问题，别被“存储过程只能写简单SQL”的传言骗了 - SQLite：截至2026年仍不支持
OVER，想实现类似效果只能用自连接或相关子查询，性能差很多
真正容易被忽略的点是：窗口函数的执行时机在WHERE、GROUP BY之后，ORDER BY之前。这意味着你不能在WHERE里直接引用SUM() OVER()的别名，哪怕它在SELECT里定义了——得套一层子查询或CTE才能过滤。
