结论是OVER(PARTITION BY)不替代GROUP BY，而是保留原行数并附加分组结果；漏写ORDER BY会导致SUM() OVER(PARTITION BY user_id)返回组内总和而非累计，加ORDER BY则变为动态累计，语义截然不同。
直接说结论：OVER(PARTITION BY) 不是用来“替代 GROUP BY”的，而是用来“在不丢行的前提下附带分组结果”的。用错场景或漏写关键子句，反而会让统计值变成全表总和或累计和，完全偏离预期。
为什么 SUM() OVER(PARTITION BY user_id) 有时返回全表总和？
这是最常踩的坑——漏写 PARTITION BY 或写成空括号。
-
SUM(amount) OVER()→ 全表求和，所有行都显示同一个总数 -
SUM(amount) OVER(PARTITION BY user_id)→ 正确：每个用户组内求和，结果重复填入该用户所有订单行 -
SUM(amount) OVER(PARTITION BY user_id ORDER BY order_time)→ 意外变成“按时间累计”，不是静态分组和
SQL Server 不会报错，但语义已彻底改变。检查方法：对比 COUNT(*) 和结果集中去重后的 user_id 数量是否一致；若不一致，大概率是窗口定义错了。
ORDER BY 在 PARTITION BY 后面加不加，结果天差地别
加 ORDER BY 不是为了排序好看，而是为了定义“累计路径”。它直接决定窗口函数是算“静态分组和”还是“动态累计和”。
- 要分组总和（如每个用户的消费总额）→ 必须不写
ORDER BY，只留PARTITION BY - 要分组累计（如每个用户按时间逐笔累加）→ 必须写
ORDER BY，且字段要有业务顺序意义 - 同值排序风险：若
ORDER BY create_time存在多笔同秒订单，SQL Server 可能将它们视为同一逻辑位置，导致累计值“跳变”。补救方式是追加唯一列，如ORDER BY create_time, id
注意：ROW_NUMBER()、RANK() 这类排名函数必须配 ORDER BY，否则报错；而 SUM()、AVG() 这类聚合函数加了 ORDER BY 就自动切换为累计语义。
PARTITION BY 字段没索引，性能可能断崖下跌
窗口函数本身不走索引，但 SQL Server 执行 OVER(PARTITION BY user_id ORDER BY created_at) 时，内部要对每个分区做排序。若缺失 (user_id, created_at) 联合索引，执行计划里必然出现 Sort 算子，大数据量下内存暴涨、tempdb 压力陡增。
- 建索引优先级：
user_id必须在联合索引最左，created_at紧随其后 - NULL 值影响：SQL Server 默认把
NULL当作最小值参与排序，若分区字段含大量NULL，可能意外合并出一个超大“NULL 分区”，拖慢整体速度 - 验证方式：在 SSMS 中看实际执行计划，重点找
Window Spool或Sort节点的 I/O 和内存估算值
兼容性与降级方案：老版本 SQL Server 怎么办？
SQL Server 2005+ 全面支持标准窗口函数，但如果你面对的是 SQL Server 2000 或更老环境（虽然极少见），OVER 语法直接报错。
- 不能用子查询模拟
SUM() OVER(PARTITION BY)—— 自连接或相关子查询在大数据量下极易超时 - 可行折中：用临时表 +
GROUP BY预聚合，再JOIN回原表。虽多一步，但可控、可加索引 - MySQL 5.7 用户注意：它不支持窗口函数，
OVER会触发ERROR 1064；必须升到 8.0+ 或改用变量模拟
真正容易被忽略的是：PARTITION BY 的语义强度远超“分组”字面意思——它定义了计算作用域的边界，而 ORDER BY 不只是排序，它是累计逻辑的执行顺序契约。哪怕业务上觉得“顺序无所谓”，数据库也必须知道哪一行该先加、哪一行该后加，否则累计就失去确定性。
