ROWS BETWEEN 必须配合 ORDER BY 才生效，否则报错或行为不可靠，因窗口边界依赖行序；无排序时“前几行”“后几行”无定义。
ROWS BETWEEN 必须配合 ORDER BY 才生效
没有 ORDER BY 的 OVER 子句里写 ROWS BETWEEN 会报错或行为不可靠——因为窗口边界依赖行序，而无排序时“前几行”“后几行”根本无定义。PostgreSQL 报 ERROR: window frame with ROWS must have ORDER BY；SQL Server 虽不报错但结果随机；MySQL 8.0+ 直接拒绝解析。
实操建议：
- 先确认业务逻辑是否真需要基于物理顺序（比如按时间戳、ID 递增）滑动，而不是逻辑分组内聚合
- 若用时间字段排序，注意
NULL值处理：加ORDER BY event_time ASC NULLS LAST（PostgreSQL）或ORDER BY ISNULL(event_time), event_time（SQL Server） - 避免用
SELECT *后再ORDER BY，列别名在OVER中不可见，排序必须用原始列或表达式
ROWS BETWEEN CURRENT ROW AND 1 FOLLOWING 的实际效果
这是最常被误解的写法：它不是“取当前行和下一行”，而是“从当前行开始，到下一行结束”，共两行参与计算。如果当前行是第 5 行，窗口就包含第 5 行和第 6 行；到了第 6 行，窗口变成第 6 行和第 7 行——严格滑动，不重叠累积。
常见错误现象：
- 误以为能拿到“当前 + 下一行”的值做条件判断（如
CASE WHEN LEAD(val) > val THEN ...），其实应优先考虑LEAD/LAG函数 - 在
COUNT(*)窗口里用ROWS BETWEEN CURRENT ROW AND 1 FOLLOWING，结果恒为 2（除非最后一行，此时为 1），而非累计计数 - 与
RANGE混用：比如RANGE BETWEEN CURRENT ROW AND INTERVAL '1 day' FOLLOWING是按值范围，而ROWS是按行数，二者语义完全不同
性能陷阱：ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 在大数据量下很慢
这个写法看起来合理（比如求累计和），但实际执行时，数据库需为每一行重新扫描从第一行到当前行的所有数据。当表有千万级记录且无合适索引时，PostgreSQL 可能退化为 O(n²)，SQL Server 容易触发大量 tempdb spill。
优化建议：
- 确保
ORDER BY列上有索引，例如CREATE INDEX idx_orders_on_date ON orders (order_date, order_id) - 若仅需最新 N 条累计值，改用
ROWS BETWEEN N PRECEDING AND CURRENT ROW，让优化器有机会用环形缓冲区 - 对实时性要求不高的场景，预计算累计值存入物化视图或汇总表，避免每次查询都重算
不同数据库对 UNBOUNDED 的兼容写法差异
UNBOUNDED PRECEDING 和 UNBOUNDED FOLLOWING 是 SQL 标准写法，但部分旧版本或嵌入式数据库支持有限。MySQL 5.7 不支持 UNBOUNDED，必须显式写数字（如 ROWS BETWEEN 1000000 PRECEDING AND CURRENT ROW）；SQLite 3.25+ 支持但不支持 FOLLOWING 方向的 UNBOUNDED。
实操要点：
- 用
SELECT version()或对应函数确认数据库版本，别只查文档版本号 - 跨库迁移时，把
UNBOUNDED PRECEDING替换为足够大的负数（如-999999999），比硬编码行数更安全 - 测试边界情况：空表、单行表、全
NULL排序列，某些引擎对UNBOUNDED的空窗口返回NULL而非 0，影响后续COALESCE逻辑
ROWS BETWEEN 的精度控制全靠排序稳定性与边界定义。最容易被忽略的是：当你在 WHERE 之后加窗口函数时，ROWS 的“当前行”已经是过滤后的结果集中的位置，而非原始表位置——这个偏移量一旦没意识到，整个滑动逻辑就全偏了。 
