ROWS BETWEEN 的窗口大小必须为字面量，不支持变量、参数或子查询；动态效果需应用层拼接SQL或改用RANGE+时间补全方案，并确保ORDER BY含唯一后缀以保证结果稳定。
ROWS BETWEEN 的窗口大小不能动态传参，必须写死为字面量
SQL 标准和主流数据库（PostgreSQL、SQL Server、Databricks SQL、MySQL 8.0+）都不支持把 ROWS BETWEEN n PRECEDING AND m FOLLOWING 中的 n 或 m 写成变量、参数或表达式。你看到的任何“动态”效果，都是靠外部逻辑拼接 SQL 字符串实现的，不是窗口子句本身支持动态。
原因很直接：窗口框架（frame）在查询编译阶段就要确定内存布局和扫描路径，而变量值只有执行时才可知，二者生命周期不匹配。
-
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW✅ 合法 -
ROWS BETWEEN @n PRECEDING AND CURRENT ROW❌ 所有引擎报错，如 SQL Server 提示 “Incorrect syntax near '@n'” -
ROWS BETWEEN (SELECT 2) PRECEDING AND CURRENT ROW❌ 不被允许，子查询不被接受
想让窗口大小可配置？只能靠应用层拼接或 CTE 预计算
如果你需要按不同业务规则切换窗口长度（比如前端选“3日”“7日”“30日”），就得把 ROWS BETWEEN 这部分当字符串处理：
- 在 Python/Java 等应用代码中，用
f"ROWS BETWEEN {days-1} PRECEDING AND CURRENT ROW"拼出完整 SQL，再执行 - 在存储过程中（如 SQL Server 的
sp_executesql），先构造含字面量的 SQL 字符串，再动态执行 - 避免用 CTE 或视图“模拟动态”——CTE 无法把窗口大小参数化，最终仍要落到具体数字
注意：拼接时务必校验 days 是正整数，防止注入或语法错误。例如传入 -1 会导致 -1 PRECEDING，部分数据库会静默转成 0 PRECEDING，但行为不可靠。
替代方案：用 RANGE BETWEEN + 时间补全，间接实现“时间维度动态”
如果你真正想要的是“过去 N 天”的滚动统计，而不是“前 N 行”，那就别硬扛 ROWS —— 它只认物理行序，对缺失日期无感。正确路径是：
- 先用
GENERATE_SERIES（PostgreSQL）、递归 CTE（SQL Server/MySQL）或日历表补全目标时间范围 - LEFT JOIN 原始数据，用
COALESCE(value, 0)填缺 - 再套
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW（固定数字），此时“6”对应“7天”就稳定了
这样，“动态”就转移到了生成日期序列的逻辑里（比如 GENERATE_SERIES(start_date, end_date, INTERVAL '1 day')），而非窗口子句本身。
容易忽略的关键点：PARTITION BY + ORDER BY 的组合稳定性比窗口大小更重要
很多人花大力气折腾怎么“动态改窗口大小”，却忽略了更致命的问题：一旦 PARTITION BY 或 ORDER BY 字段存在重复值，哪怕窗口大小写死为 2 PRECEDING，结果也会每次执行不一致。
比如按 order_time 排序，但多笔订单同毫秒下单——数据库可能任意调整这些行的物理顺序，导致同一行的“前两行”内容漂移。这不是 bug，是未定义行为。
解决方法只有一条：ORDER BY 必须带唯一后缀，例如：ORDER BY order_time, order_id 或 ORDER BY event_time, log_id。否则，窗口大小再“动态”也没意义——结果根本不可复现。
