用AVG() OVER(PARTITION BY ...)可在每行显示所属分组的静态平均值，不减少行数；必须显式指定PARTITION BY，避免误用GROUP BY或漏写导致全表平均、行数丢失或动态窗口。
用 AVG() OVER() 同时显示原行和组内平均值
想在每行旁边附上它所属分组的平均值，而不是只返回一行聚合结果？直接用 AVG() OVER(PARTITION BY ...) 就行，它不会折叠原始行数，而是“广播”平均值到每条匹配记录上。
常见错误是误写成 GROUP BY + AVG()，结果行数变少、原始字段丢失；或者漏写 PARTITION BY，导致算出全表平均值，和预期分组不符。
- 必须显式写
PARTITION BY，否则默认按整张表计算 -
ORDER BY在OVER里不是必须的，加了会影响窗口范围（比如变成累计平均），不加才对应“整个分组的静态平均” - 如果分组字段有
NULL，它们会被归为同一组——这是 SQL 标准行为，不是 bug，但容易被忽略
SELECT id, dept, salary,
AVG(salary) OVER (PARTITION BY dept) AS avg_dept_salary
FROM employees;
OVER() 里不加 ORDER BY 才对得上“每组平均值”
一旦在 OVER 子句里加上 ORDER BY，比如 AVG(salary) OVER (PARTITION BY dept ORDER BY hire_date)，窗口就从“整组”变成“从第一行到当前行”的累积窗口，结果不再是该组固定平均值，而是随排序位置变化的滚动均值。
典型误用场景：复制了其他分析函数（如 ROW_NUMBER()）的写法，顺手加了 ORDER BY，结果数值飘忽不定，还查不出原因。
- 要静态组平均 → 只用
PARTITION BY，不写ORDER BY - 要按时间顺序看趋势 → 才加
ORDER BY，但得接受它是动态窗口 - 某些数据库（如 PostgreSQL）支持
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING显式声明整组，但多数情况纯PARTITION BY更简洁可靠
空值（NULL）参与计算时的隐性影响
AVG() 默认忽略 NULL 值，但前提是这些 NULL 出现在被聚合的列（比如 salary）中；而分组键（比如 dept）如果是 NULL，会单独成一组——这点常被当成数据脏乱，其实是标准行为。
更隐蔽的问题是：如果想把 NULL 当 0 处理再算平均，不能靠 AVG(COALESCE(salary, 0)) 简单替代，因为语义变了（分母还是非空行数），得用 SUM() / COUNT(*) 配合 COALESCE 手动算。
-
AVG(salary)跳过salary IS NULL的行，分母是有效值个数 -
AVG(COALESCE(salary, 0))把NULL当 0 加入计算，但分母仍是原有效行数 → 结果偏低 - 真要“全行参与、
NULL算 0”，得写：SUM(COALESCE(salary, 0)) * 1.0 / COUNT(*)
和 GROUP BY 混用时的字段可见性问题
如果在同一个查询里既用 GROUP BY，又用 AVG() OVER()，要注意：窗口函数能访问所有原始字段，但 SELECT 列表里非聚合、非分组字段会报错（除非在支持 functional dependency 的数据库如 PostgreSQL 14+ 中）。
本质矛盾在于：GROUP BY 要求逻辑上“降维”，而 OVER 是“升维”操作。强行混用容易触发语法错误或意料外结果。
- 目标是“每组一条 + 附带组平均” → 用
GROUP BY+AVG()即可，别加OVER - 目标是“每行保留 + 多个维度的组平均（比如按部门、按年份分别算）” → 只用多个
AVG() OVER()，不要GROUP BY - MySQL 8.0+ 和 SQL Server 允许在
GROUP BY查询中使用窗口函数，但SELECT里非分组字段仍需明确处理，不能裸写
真正麻烦的不是语法写不对，而是看到结果数字“差不多”就以为对了——比如分组键含 NULL 时多出一组，或者 ORDER BY 悄悄启用了累积窗口，平均值看着合理，实际业务含义已经偏了。
