GROUP BY 会减少行数是因为它将多行压缩为一行，而窗口函数可在保留原行基础上附带计算；正确写法是 SUM(amount) OVER (PARTITION BY user_id)，漏写 PARTITION BY 或误加 ORDER BY 会导致结果错误。
为什么 GROUP BY 会减少行数，而你需要保留原行？
因为 GROUP BY 是聚合操作的本质行为：它把多行压缩成一行。如果你原始有 1000 条订单记录，按用户 ID 分组后，结果只有 200 行——这和“每条订单旁显示该用户的总消费额”这种需求冲突。
真正要的是：不折叠数据，只“附带计算”。窗口函数就是干这个的，它在保持每一行原始结构的前提下，注入统计值。
SUM() OVER (PARTITION BY ...) 是最常用也最容易写错的写法
错误常出现在漏写 PARTITION BY 或误加 ORDER BY 导致累计和（而非分组和）。比如想算每个用户的订单总额并挂在每条订单上：
- ✅ 正确：
SUM(amount) OVER (PARTITION BY user_id)—— 每个 user_id 组内求和，结果重复填入该组所有行 - ❌ 错误：
SUM(amount) OVER ()—— 全表求和，所有行都得到同一个总数 - ⚠️ 隐患：
SUM(amount) OVER (PARTITION BY user_id ORDER BY order_time)—— 变成“截止到当前订单的时间累计和”，不是静态分组和
不同数据库对窗口函数的支持差异会影响你能不能用
MySQL 8.0+、PostgreSQL 8.4+、SQL Server 2005+、Oracle 8i+ 都支持标准窗口语法；但 SQLite 要 3.25.0+，且不支持 RANGE 帧定义；老版本 MySQL（5.7）直接报错 ERROR 1064。
检查方法很简单，在命令行或客户端执行：SELECT SUM(1) OVER ()，能返回结果就说明支持基础窗口函数。
- PostgreSQL 支持
FRAME子句精细控制范围，如ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW - MySQL 8.0 默认使用
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，若列含重复值可能意外扩大窗口 - 如果必须兼容旧版 MySQL，只能用自连接或子查询模拟，性能差、易出错
性能陷阱：没加索引的 PARTITION BY 字段会让窗口函数变慢
窗口函数本身不走索引，但数据库优化器在做分区排序时，会依赖 PARTITION BY 和 ORDER BY 字段上的索引。比如：OVER (PARTITION BY user_id ORDER BY created_at)，若表没有 (user_id, created_at) 联合索引，执行计划里大概率出现 Sort 节点，大数据量下 I/O 和内存开销陡增。
- 观察执行计划：找
WindowAgg或WindowFunc节点是否伴随大块Sort - 建索引优先级：
PARTITION BY字段必须在联合索引最左，ORDER BY字段紧随其后 - 注意 NULL 值：某些数据库（如 PostgreSQL）默认把 NULL 当作最小值参与排序，可能打乱预期分组边界
PARTITION BY 的语义边界一旦和业务理解错位（比如把 status 当分组键却忽略 NULL 状态），统计结果就会静默出错——这种问题往往上线后才暴露，查起来特别费劲。 
