AVG() OVER(PARTITION BY)是唯一能逐行计算并保留原始行的组内均值方法；混用GROUP BY、漏写PARTITION BY、在WHERE中直接使用窗口函数均为常见错误，须用子查询或CTE先计算再过滤。
AVG() OVER(PARTITION BY) 是唯一可行路径
想逐行对比当前值和组内平均值，必须用窗口函数，不能用 GROUP BY —— 后者会把每组压成一行，原始行就没了。核心是：保留所有原始行，同时为每行附上它所属分组的平均值。这只有 AVG() OVER(PARTITION BY group_col) 能做到。
常见错误包括：
- 在同一个查询里混用
GROUP BY和AVG() OVER()，数据库要么报错（如 PostgreSQL），要么静默丢弃窗口逻辑（如旧版 MySQL） - 漏写
PARTITION BY，结果变成全表均值，不是“组内”均值 - 把
AVG()直接写进WHERE，语法不通过：WHERE salary > AVG(salary) OVER(PARTITION BY dept)会报错
差值计算必须套在子查询或 CTE 里
窗口函数只能出现在 SELECT 子句中，不能直接用于过滤。所以“找出高于组均值的数据”，得先算出均值列，再在外层筛选。
推荐写法（子查询）：
SELECT dept, name, salary
FROM (
SELECT dept, name, salary,
AVG(salary) OVER (PARTITION BY dept) AS avg_dept_salary
FROM employees
) t
WHERE salary > avg_dept_salary;要点：
- 别用相关子查询替代，比如
(SELECT AVG(salary) FROM employees e2 WHERE e2.dept = e1.dept)，性能差一个数量级 - CTE 写法更易读，但执行计划通常和子查询一致，选哪个看团队习惯
- 如果业务要求“等于均值也算”，注意浮点误差：用
ROUND(AVG(salary) OVER(...), 2)避免salary = 10000.0却因精度问题判为false
PARTITION BY 列必须和业务分组完全一致
分组键错一个字符、少一个条件，均值就偏了。例如按部门统计，但数据里有 'R&D' 和 'R&D' 两种写法，PARTITION BY dept 会当成两个组分别算——这不是函数问题，是数据质量问题。
实操建议：
- 先跑一遍
SELECT dept, COUNT(*) FROM employees GROUP BY dept ORDER BY 2 DESC，人工扫一眼分组值是否合理 - 涉及多字段分组（如
PARTITION BY region, product_category），确保这些列在WHERE中没被意外过滤掉 - 若某组全为
NULL值，AVG()返回NULL，差值列也会是NULL；业务上需明确是否要COALESCE(AVG(...), 0)或标记为异常
浮点精度和类型陷阱最容易被忽略
整数列（如 INT salary）走 AVG()，不同数据库返回类型不同：MySQL 默认 DECIMAL，PostgreSQL 返回 numeric，SQLite 返回 REAL。混合运算时可能隐式转成浮点，导致 salary - AVG() 出现 -0.0000001 这类值。
稳妥做法：
- 显式控制小数位：
ROUND(salary - AVG(salary) OVER(PARTITION BY dept), 2) - 强制类型一致：
CAST(AVG(salary) OVER(...) AS DECIMAL(10,2)) - 整数列参与平均前乘
1.0或用AVG(CAST(salary AS FLOAT))，避免某些引擎截断小数
真正难处理的不是语法，而是当 salary 本身是 NULL，或某部门全员 NULL 时，差值列全为 NULL —— 这时候前端显示空白，但没人知道是数据缺失，还是计算失败。
