报错“frame start cannot be greater than frame end”是因ROWS BETWEEN起始偏移量大于结束偏移量，如5 PRECEDING AND 1 PRECEDING；须确保同向偏移且数值满足n≤m，固定行数用ROWS，防重复值干扰用RANGE。
ROWS BETWEEN 报错“frame start cannot be greater than frame end”
这是最常见的一击即溃式错误，本质是窗口帧定义里 ROWS BETWEEN 的起始行偏移量大于结束偏移量。比如写成 ROWS BETWEEN 5 PRECEDING AND 1 PRECEDING，起始是当前行往前数第5行，结束是往前数第1行——这在逻辑上就是空集，PostgreSQL 和大多数主流数据库会直接报错，而不是静默返回空结果。
实操建议：
- 检查偏移方向是否一致：两个偏移都该用
PRECEDING或都用FOLLOWING，混用极易出错 - 确认数值大小关系：若用
n PRECEDING AND m PRECEDING，必须满足n ；同理，<code>n FOLLOWING AND m FOLLOWING要求n - 想表达“只看前5行”，就写
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW（含当前行共5行），别写5 PRECEDING AND 1 PRECEDING
固定行数窗口 vs 固定时间窗口：ROWS 和 RANGE 的关键区别
ROWS BETWEEN 算的是物理行数，不管这些行对应的时间值是否连续或重复；而 RANGE BETWEEN 按排序键的值范围切片，对时间字段更自然，但容易在重复值处“吞掉”多行。
举个例子：按 order_time 排序后，用 RANGE BETWEEN INTERVAL '1 hour' PRECEDING AND CURRENT ROW，如果某分钟内有100条订单，它们全被算进同一个窗口；但换成 ROWS BETWEEN 99 PRECEDING AND CURRENT ROW，就严格取最近100条，无论时间跨度是1秒还是3小时。
实操建议：
- 要稳定控制参与计算的记录条数（比如“每10条滚动平均”），必须用
ROWS - 用
RANGE前先确认排序字段无大量重复值，否则窗口实际覆盖行数远超预期 - MySQL 8.0+、PostgreSQL、SQL Server 都支持
ROWS；旧版 MySQL（
ORDER BY 必须存在，且不能只靠 GROUP BY
只要用了 ROWS BETWEEN，SQL 标准就强制要求窗口定义中带 ORDER BY。哪怕你只是想对整个表做固定行数聚合（比如“全表前10行求和”），也得显式写 ORDER BY id 或类似字段——没有排序，数据库无法确定哪是“前”哪是“后”。
常见错误现象：Window definition requires an ORDER BY clause（PostgreSQL）、This function requires an ORDER BY clause（MySQL）。
实操建议：
- 别指望
GROUP BY能替代ORDER BY；两者语义完全不同 - 如果业务上真无所谓顺序，选一个有索引、非 NULL、唯一性高的字段（如主键
id）来ORDER BY - 避免用表达式或函数结果排序（如
ORDER BY RANDOM()），会导致窗口行为不可复现，调试困难
性能陷阱：大偏移量 + 无索引 ORDER BY 字段
ROWS BETWEEN 10000 PRECEDING AND CURRENT ROW 看似简单，但如果 ORDER BY 字段没索引，数据库每次计算都要重排整个分区，O(n²) 时间复杂度可能让查询卡死。
使用场景举例：实时风控中计算“过去1万笔交易的平均金额”，数据量千万级，ORDER BY created_at 却没建索引——第一次跑就超时。
实操建议：
- 确保
ORDER BY字段上有有效索引，尤其是偏移量大于几百时 - 避免在
ORDER BY中混用 ASC/DESC（如ORDER BY a ASC, b DESC），部分数据库优化器对混合方向支持弱 - 测试时用
EXPLAIN看执行计划，重点确认是否走了索引扫描，而非排序节点（Sort）出现在顶层
真正难的不是写对语法，而是想清楚：你要的到底是“最近N条”的确定性，还是“过去N小时”的业务意义。前者靠 ROWS，后者靠 RANGE，选错一个，结果就偏到隔壁系统去了。
