range按逻辑值分组处理重复日期，rows按物理行逐行滑动；mysql 8.0对date类型不支持range+interval，需转为整数列 workaround；默认隐式帧为range，易致累计逻辑错误，应显式声明rows或range。
处理重复日期时，RANGE会把同一天所有行“打包”进同一个窗口
当 ORDER BY 列是日期（如 order_date），且存在多笔订单落在同一天时，ROWS 严格按物理顺序逐行滑动——哪怕第2、3、4行都是 '2026-02-01'，它也只拉固定行数（比如 2 PRECEDING AND CURRENT ROW 就只取前两行+当前行），结果可能漏掉同日其他记录。
RANGE 则不同：它看的是值本身。只要排序列的值相等（比如都是 '2026-02-01'），就视为一个逻辑组；再配合 BETWEEN ... AND ... 的值范围（如 RANGE BETWEEN INTERVAL '6' DAY PRECEDING AND CURRENT ROW），所有落在该时间区间内的行全被纳入，不管那天有多少笔。
常见错误现象：
- 用 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 算“过去7天销售额”，但某天有50单，下一天只有1单 → 窗口实际覆盖不到完整7天，而是最近7行（可能只含3天）
- RANGE 在这种场景下才真正表达“时间区间”，不是“行数区间”
MySQL 8.0+ 对 RANGE + 日期的支持有限，别直接套用 PostgreSQL 写法
PostgreSQL 和 Oracle 支持 RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW 这类写法，但 MySQL 8.0+ 仅对数字类型（如 INT、DECIMAL）原生支持 RANGE 值范围计算；对 DATE 或 DATETIME，MySQL 不接受 INTERVAL 表达式，会报错：ERROR 3589 (HY000): Window frame 'RANGE' with offset must be of type numeric
实操建议：
- 若必须用 MySQL 且需日期范围窗口，改用 ROWS + 辅助列：先将日期转为整数（如 TO_DAYS(order_date)），再对这个整数列 ORDER BY 并用 RANGE BETWEEN 6 PRECEDING AND CURRENT ROW
- 或退而求其次，用子查询 + 自连接模拟时间范围，但性能明显下降
- PostgreSQL 用户可直接用 RANGE BETWEEN INTERVAL '6' DAY PRECEDING AND CURRENT ROW，无需转换
默认隐式帧是 RANGE，不显式声明容易踩逻辑坑
几乎所有主流数据库（包括 MySQL、PostgreSQL、SQL Server）在你只写 ORDER BY 却没写 ROWS 或 RANGE 时，都默认采用 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。这意味着：哪怕你本意是“逐行累加”，只要 ORDER BY 列有重复值，结果就会跳变——比如按 sale_date 累计，3月1日有10单，那这10行的累计值全一样，等于前N天所有销售额总和。
容易忽略的点：
- SUM(amount) OVER (ORDER BY sale_date) ≠ 逐行滚动加总，而是“截至该日期的所有数据”
- 要真正逐行累加，必须显式写成 SUM(amount) OVER (ORDER BY sale_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
- 生产环境强烈建议禁用隐式帧，所有 OVER() 都明确带上 ROWS 或 RANGE
RANGE 的性能开销通常高于 ROWS，尤其在高基数日期列上
ROWS 只需维护一个行号指针，滑动成本是 O(1)；RANGE 需要对每个当前行，在排序键值域内做范围查找（类似索引范围扫描），当分区大、重复值少（比如每天就1单）、且排序列是 DATETIME(6) 这种高精度类型时，RANGE 实际要检查的候选行数可能远超预期。
判断依据：
- 查看执行计划：MySQL 中若出现 Using filesort; Using temporary 且窗口函数耗时突增，大概率是 RANGE 引发的隐式排序放大
- 在 PostgreSQL 中可通过 EXPLAIN (ANALYZE) 观察 WindowAgg 节点的 Rows Removed by Filter 是否异常高
- 如果业务只要“最近N笔”，而非“最近N天”，优先用 ROWS —— 它更可控、更快、行为确定
