min over不能替代group by，因其为窗口函数，保留原始行数并附加计算值，而group by压缩行数输出聚合结果；二者作用层级与语义目标根本不同。
MIN OVER 为什么不能直接当 GROUP BY 用
因为 MIN OVER 是窗口函数，它不压缩行数，而 GROUP BY 会聚合掉重复行。如果你想要“每个分组的最小值”作为新列参与后续计算（比如算偏离度、标准化），就必须用窗口函数；但若只是想查出每个分组一条记录，MIN OVER 就是绕远路，该用 GROUP BY + 聚合或 ROW_NUMBER() 配合 WHERE 过滤。
正确写法：PARTITION BY + ORDER BY 的取舍
MIN OVER 的核心是 PARTITION BY，它定义分组边界；ORDER BY 在这里**完全多余**——MIN 不依赖顺序，加了反而可能误导自己以为在做累积最小值。常见错误是写成 MIN(price) OVER (PARTITION BY category ORDER BY date)，这其实等价于“到当前行为止的最小值”，不是全组最小值。
- 要全组最小值：只写
PARTITION BY category，去掉ORDER BY - 要按时间滚动最小值：才加
ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW - PostgreSQL / SQL Server / Oracle / BigQuery 都支持无
ORDER BY的MIN OVER，MySQL 8.0+ 同样支持
和 GROUP BY + JOIN 比，性能差在哪
直接用 MIN OVER 通常比先 GROUP BY 再 JOIN 回原表快，因为避免了一次哈希连接或嵌套循环。但要注意：如果原表很大且分区键选择性低（比如只有 3 个 category 值），MIN OVER 仍需扫描全表并维护窗口状态，内存压力可能上升。
- 有索引时：
PARTITION BY category若能走category索引前缀，效率更稳 - 没索引时：数据库可能对每组做全表扫描找最小值，不如显式
GROUP BY+ 索引优化可控 - 别在
SELECT *场景滥用：只选需要的列，避免把大文本字段也拖进窗口计算
容易被忽略的 NULL 处理陷阱
MIN 默认忽略 NULL，但如果整组全是 NULL，结果就是 NULL，不会报错也不会跳过。这在做基准参考值时很危险——比如你想用最小价格做折扣锚点，结果某类商品全没标价，MIN(price) OVER (PARTITION BY category) 返回 NULL，后续除法或比较就全崩了。
- 显式处理：
COALESCE(MIN(price) OVER (PARTITION BY category), 0)或999999 - 更安全做法：
MIN(COALESCE(price, 999999)) OVER (PARTITION BY category)，先转再算，避免整组NULL导致结果NULL - 注意：不同数据库对
COALESCE和窗口函数嵌套的支持一致，但 Hive/SparkSQL 对COALESCE内部含窗口函数有时解析失败，得拆成子查询
GROUP BY 更直白；前者才轮到 MIN OVER 出场——而且必须盯紧 PARTITION BY 的粒度、NULL 的语义、以及目标数据库对空组的返回行为。
