MySQL 5.7及更早版本在存储过程中直接使用窗口函数会报ERROR 1064，因其不支持OVER语法；MySQL 8.0+、PostgreSQL、SQL Server等才支持，使用前须执行SELECT VERSION()确认版本。
存储过程里直接用窗口函数会报错？先确认数据库版本
MySQL 5.7 或更早版本不支持窗口函数，ROW_NUMBER()、SUM() OVER() 这类写法在存储过程中会直接抛出 ERROR 1064。PostgreSQL 8.4+、Oracle 8i、SQL Server 2005+ 和 MySQL 8.0+ 才真正支持。别在旧版 MySQL 存储过程中硬塞 OVER()，它根本解析不了。
验证方法很简单：
SELECT VERSION();
如果是 8.0.33 或更高，继续；如果是 5.7.42，就得换思路——要么升级，要么用临时表 + 自连接模拟窗口逻辑。
为什么不能在存储过程的 DECLARE 中直接定义窗口函数结果
窗口函数不是标量值，不能赋给 DECLARE @var DECIMAL 这类变量。你写 SET @rank = RANK() OVER (ORDER BY score) 会报 ERROR 1242: Subquery returns more than 1 row —— 因为窗口函数天生返回多行，而变量只能存单个值。
正确做法是把窗口计算放在查询主体中，再让存储过程封装整条查询：
- 用
CREATE TEMPORARY TABLE接收带窗口函数的结果集（推荐，可控性强） - 用游标逐行处理？不建议——窗口函数本意就是向量化计算，游标反而抵消优势
- 若必须返回单值（比如“Top 3 平均销售额”），先用窗口函数筛出行，再套一层
AVG()聚合
在存储过程中组合窗口 + 聚合时，ORDER BY 是隐式陷阱
这条语句看着没问题：
SELECT product_id, SUM(amount) OVER (PARTITION BY product_id) AS total FROM sales;
但放进存储过程后，如果后续要 GROUP BY product_id 做二次聚合，MySQL 可能因缺少显式 ORDER BY 报错或返回不稳定顺序——尤其当 PARTITION BY 字段存在重复值且未指定排序依据时。
安全写法必须补全 ORDER BY，哪怕只是加个主键：
SUM(amount) OVER (PARTITION BY product_id ORDER BY sale_id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
否则在高并发写入场景下，同一存储过程多次执行可能产出不同 RANK() 结果。
性能崩盘常发生在存储过程嵌套调用窗口函数时
比如外层存储过程调用内层存储过程，内层又查一张没索引的订单表并跑 LAG()，整个链路就会触发全表扫描 × N 次。PostgreSQL 的执行计划里会出现多个 WindowAgg 节点嵌套，耗时指数增长。
关键规避点：
-
PARTITION BY和ORDER BY字段必须有联合索引，例如CREATE INDEX idx_user_time ON orders(user_id, create_time); - 避免在存储过程中对大表做无 WHERE 条件的窗口计算，先用
WHERE date >= '2026-01-01'切分数据范围 - 如果窗口逻辑固定（如“近30天滚动销量”），考虑物化为每日定时更新的汇总表，而非每次调用都实时算
最易被忽略的是：窗口函数在存储过程中无法利用查询缓存（MySQL Query Cache 已废弃，但 Plan Cache 仍受参数影响），所以每次 EXECUTE 都重新生成执行计划——分区字段选择不当，就等于每次都在裸跑全表排序。
