ROWS按物理行号计数，RANGE按ORDER BY列值分组；ROWS将每行视为独立个体逐行计算，RANGE将同值行视为同一逻辑单元整体纳入窗口，导致重复值下结果批量相同，性能上ROWS为O(1)游标访问，RANGE最坏O(n²)值域扫描。
ROWS按行号计数，RANGE按值分组
根本区别不在语法，而在数据库怎么理解“当前行”：ROWS把每一行当独立个体，严格按物理顺序数“第几行”；RANGE把所有ORDER BY列值相同的行视为一个逻辑单元，窗口边界落在值域上，不是行号上。
比如score列有重复：id=1（80）、id=2/3/4（85）、id=5（90）。用SUM(score) OVER (ORDER BY score ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)，第2、3、4行结果分别是165、250、335——逐行累加；换成RANGE后，第2–4行结果全是335，因为它们共享同一个score = 85，RANGE把这三行打包成一个点来计算累计。
RANGE在重复值多时会“吞并”整组行
这不是bug，是设计行为。只要ORDER BY字段值相同，RANGE就认为这些行处于同一逻辑位置，窗口边界会一次性覆盖全部同值行。
- 常见错误现象：按
DATE(created_at)排序做累计，某天有200条日志，RANGE会让当天所有200行的累计值完全一样，等于前N天总和 - ROWS则不会：哪怕同一天，它也只取当前行+前面指定行数，结果逐行递增
- MySQL 8.0+对
DATE类型不支持RANGE BETWEEN INTERVAL '7 days' PRECEDING，直接报错ERROR 3589，必须先转成TO_DAYS(date_col)再用
业务语义决定该用哪个，不是数据分布
别看数据里重复多就换ROWS——如果业务要的是“截至当前分数的所有人销量”，RANGE才是对的；如果要的是“截至当前第N名学生的总分”，ROWS才符合定义。
容易踩的坑：
- 默认没写
ROWS或RANGE时，几乎所有数据库（PostgreSQL/MySQL/SQL Server）都隐式补RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，你以为在逐行累加，实际在按值分组累加 -
LAG()/LEAD()必须用ROWS，RANGE无法定义“上一行”——它连“行”都不认，只认“值” - 用
LAST_VALUE(x) OVER (ORDER BY ts)总返回当前行，就是因为默认RANGE帧只覆盖到当前值，不是整个分区
性能差异来自底层定位方式
ROWS靠游标偏移，O(1)随机访问；RANGE得对每一行重新扫描满足值条件的边界，最坏O(n²)，尤其当ORDER BY列大量重复时。
实操建议：
- 上线前必须用真实数据跑
EXPLAIN ANALYZE，对比Actual Total Time——RANGE常比等效ROWS慢3–10倍 - 复合索引要严格按
PARTITION BY字段在前、ORDER BY字段在后，比如(user_id, event_time)，反过来无效 - 别指望索引能救RANGE的性能，它本质是逐行重查，索引只能缓解，不能改变O(n²)复杂度
真正难的不是写对语法，而是想清楚：你算的到底是“位置”还是“值域”。时间跨度、价格区间、等级分档——这些词背后都是RANGE；笔数、行数、排名——这些词背后才是ROWS。
