ROWS按物理行号逐行计算，RANGE按ORDER BY列值分组聚合；重复值使RANGE将多行视为同一逻辑点，导致累计结果相同，而ROWS仍逐行累加；LAG/LEAD等函数必须显式指定ROWS，因RANGE无法定义前后行关系。
因为ROWS按物理行号计数，RANGE按ORDER BY列的值分组——重复值会让RANGE把多行“打包”进同一个窗口帧，而ROWS仍一行一行往下数。
ROWS逐行累加，RANGE批量吞并同值行
当ORDER BY字段（如score、DATE(created_at)）存在重复时，ROWS严格按排序后的位置编号处理：第1行、第2行……哪怕score = 85连续出现3次，它们的累计值分别是前1行+当前行、前2行+当前行、前3行+当前行。
RANGE则无视行号，只看值：所有score = 85的行被视作同一逻辑点，窗口边界落在值域上。所以这3行的SUM() OVER (ORDER BY score RANGE ...)结果完全一样，等于“所有score ≤ 85的记录之和”。
- 常见错误现象：
SUM(sales) OVER (ORDER BY DATE(order_time) RANGE ...)在某天有200单时，当天所有200行的累计值相同，直接跳到下一天 - 换成
ROWS，就是逐笔累加，中间不会跳 - 业务语义决定选哪个：要“截至当前分数的所有人”，用RANGE；要“截至当前第N名学生”，必须用ROWS
LAG/LEAD这类函数根本不能用RANGE
LAG()和LEAD()依赖明确的“上一行”“下一行”概念，而RANGE不认“行”，只认“值”。只要ORDER BY列值相同，RANGE就认为这些行处于同一位置，无法定义前后关系。
-
LAG(amount) OVER (ORDER BY price RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)在PostgreSQL中会报错，在MySQL中可能返回NULL - 必须显式写
ROWS：LAG(amount) OVER (ORDER BY price ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) - 同理，
LAST_VALUE(x) OVER (ORDER BY ts)默认也走RANGE帧，所以总返回当前行值——不是分区末尾值
默认隐式补RANGE，不写就等于悄悄踩坑
几乎所有数据库（PostgreSQL/MySQL 8.0+/SQL Server）在你只写OVER (ORDER BY col)却没指定ROWS或RANGE时，都会自动补上RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。
- 你以为
SUM(x) OVER (ORDER BY event_time)是逐行累加，实际跑的是值域逻辑 - 执行计划里看不到警告，但
EXPLAIN ANALYZE中WindowAgg节点若带Range字样，就是它在拖慢查询 - 尤其当
event_time精确到秒、某秒插入大量日志时，RANGE性能可能比等效ROWS慢5–10倍
MySQL对DATE类型用RANGE要特别小心
MySQL 8.0+不支持RANGE BETWEEN INTERVAL '7 days' PRECEDING这种写法，对DATE或DATETIME列直接报错：ERROR 3589 (HY000): Window frame 'RANGE' with offset must be of type numeric。
- workaround：先转成整数列，比如
TO_DAYS(order_date)或UNIX_TIMESTAMP(event_time)，再ORDER BY这个新列并用RANGE BETWEEN 6 PRECEDING AND CURRENT ROW - 别在MySQL里盲目照搬PostgreSQL的
INTERVAL写法 - 如果只是想取最近N行，直接用
ROWS更安全，也无需转换
真正难的不是记住区别，而是上线前得用真实数据跑EXPLAIN ANALYZE，确认窗口帧到底是Rows还是Range——很多问题直到查慢查询日志才发现，已经晚了。
