rows between 不接受变量或表达式，因sql标准要求帧偏移量必须是编译期确定的非负整数常量；动态偏移会导致执行引擎无法预分配内存和确定扫描范围。
为什么 ROWS BETWEEN 不接受变量或表达式
SQL 标准规定窗口帧偏移量（如 ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING 中的 1）必须是**编译期可确定的非负整数常量**，不能是列值、参数、子查询或函数调用。你写 ROWS BETWEEN n PRECEDING AND n FOLLOWING 会直接报错，常见错误信息是：frame_start or frame_end must be a non-negative integer literal（PostgreSQL / BigQuery）或 Window frame 'ROWS' cannot have dynamic offset（SQL Server 2022+ 的部分场景）。
根本原因不是数据库“不支持”，而是窗口帧在物理执行时需预先分配内存并确定滑动边界——动态偏移会让执行引擎无法静态规划缓冲区大小和扫描范围。
替代方案：用自连接 + 范围条件模拟动态帧
当需要按每行的 lookback_days 字段动态计算前 N 天的均值时，不能靠窗口函数一步到位，得退回到更基础的关系操作。
- 把原表自连接，用时间字段（如
event_date）和动态偏移字段（如t1.lookback_days）构造范围条件：t2.event_date BETWEEN t1.event_date - INTERVAL '1 day' * t1.lookback_days AND t1.event_date - 确保连接键合理（例如同用户 ID），并加
GROUP BY t1.*避免笛卡尔爆炸 - 聚合时用
AVG(t2.value)替代AVG() OVER (...)，逻辑等价但可控
示例（PostgreSQL）：
SELECT
t1.user_id,
t1.event_date,
t1.lookback_days,
AVG(t2.value) AS rolling_avg
FROM events t1
JOIN events t2
ON t2.user_id = t1.user_id
AND t2.event_date BETWEEN t1.event_date - (t1.lookback_days || ' days')::INTERVAL
AND t1.event_date
GROUP BY t1.user_id, t1.event_date, t1.lookback_days;
用递归 CTE 或 LATERAL 拆解高成本场景
自连接在数据量大、偏移范围宽时容易爆炸（O(n²)）。如果动态偏移只出现在少数行，或偏移值整体较小，可用 LATERAL 把聚合下推到每行执行，避免全量连接：
-
LATERAL允许右侧子查询引用左侧字段，天然适配动态边界 - 配合
LIMIT和索引（如(user_id, event_date)）能显著提速 - 注意：MySQL 8.0+ 不支持
LATERAL，需改用相关子查询（性能更差）
PostgreSQL 示例：
SELECT
t1.user_id,
t1.event_date,
t1.lookback_days,
(SELECT AVG(value)
FROM events t2
WHERE t2.user_id = t1.user_id
AND t2.event_date BETWEEN t1.event_date - (t1.lookback_days || ' days')::INTERVAL
AND t1.event_date) AS rolling_avg
FROM events t1;
真正需要“动态窗口”的时候，先确认是否误用了窗口函数
很多所谓“动态偏移”需求，其实是对业务逻辑的误解。比如“取最近 3 笔订单金额平均值”，看似要按每行的订单数偏移，实则应先用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC) 标记序号，再用 WHERE rn 过滤后聚合——这不需要动态帧，且性能更好。
容易被忽略的关键点：窗口函数的“动态性”仅限于 PARTITION BY 和 ORDER BY 表达式，帧边界永远静态。一旦发现你在反复尝试让 ROWS BETWEEN 接受变量，大概率该重构思路了。
