AVG OVER算出的“部门平均薪资”是每行重复显示的窗口值，非单值标量；正确用法需通过CTE或子查询先计算再过滤，不可在WHERE中直接使用窗口函数，且须注意NULL处理、数据类型及边界情况。
AVG OVER 算出来的“部门平均薪资”到底是不是你想要的？
直接用 AVG(salary) OVER (PARTITION BY dept) 得到的是每个部门的平均值，但它会**在每一行重复出现**，不是单个标量。很多人误以为能拿它直接和 salary 比较就完事——其实可以，但必须注意：这个比较发生在窗口计算完成后的结果集里，不是在聚合前。
常见错误是写成：WHERE salary > AVG(salary) OVER (PARTITION BY dept) —— 这在标准 SQL 中非法，因为 WHERE 阶段窗口函数尚未执行。
- 正确做法是用子查询或 CTE 先算出带部门均值的中间结果，再过滤
- MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持，但 SQLite（除非 3.25+ 且启用窗口函数）不支持
-
AVG()默认忽略NULL，如果部门里有 NULL 薪资，均值分母会变小，可能抬高门槛
怎么写出可读又不出错的“部门内超均值人员”查询？
推荐用 CTE，逻辑清晰，也方便后续加排序或分页：
WITH dept_avg AS (
SELECT id, name, dept, salary,
AVG(salary) OVER (PARTITION BY dept) AS avg_dept_salary
FROM employees
)
SELECT id, name, dept, salary, ROUND(avg_dept_salary, 2) AS avg_dept_salary
FROM dept_avg
WHERE salary > avg_dept_salary;关键点：
- 别在
SELECT里写ROUND(AVG(...) OVER ..., 2)再用于WHERE—— 多数引擎不允许在同一个层级引用计算列 - 如果部门只有 1 人，
AVG就等于他本人薪资，salary > avg_dept_salary永远为假，这类边界情况要心里有数 - 想看“超过本部门平均多少”，可追加
salary - avg_dept_salary列，无需额外窗口函数
为什么用 AVG OVER 而不是 GROUP BY + JOIN？
用传统 GROUP BY dept 再 JOIN 回原表也能实现，但代价更高、语义更绕：
-
GROUP BY会丢失原始行细节（比如同部门多人，只留一条聚合记录），JOIN 后需确保关联键无歧义 - 窗口函数天然保留在原始粒度，一行一员工，字段齐全，后续扩展（如加排名、累计求和）更顺滑
- 性能上，现代优化器对简单
OVER (PARTITION BY ...)通常比等价 JOIN 更优，尤其数据量大时
不过要注意：AVG OVER 不能替代聚合统计——它不压缩行数，所以不能当“部门平均薪资报表”直接用，那是 GROUP BY 的事。
容易被忽略的 NULL 和类型陷阱
AVG(salary) 遇到 NULL 会跳过，但 salary > avg_dept_salary 这个比较中，只要任一操作数为 NULL，整条表达式结果就是 UNKNOWN，该行被 WHERE 排除——这可能导致“明明有人薪资很高却查不到”。
- 检查数据：先跑
SELECT dept, COUNT(*), COUNT(salary) FROM employees GROUP BY dept，确认COUNT(*) != COUNT(salary)的部门有哪些 - 若需把 NULL 当 0 参与计算，得显式写成
AVG(COALESCE(salary, 0)) OVER (PARTITION BY dept)，但业务上是否合理要判断 - 某些数据库（如旧版 PostgreSQL）对
AVG输入类型敏感，salary是INTEGER时，AVG结果可能是整型截断，建议显式转NUMERIC或用AVG(CAST(salary AS NUMERIC))
真正麻烦的不是语法，而是你默认“平均值”是个稳定可靠的锚点——它其实高度依赖数据质量和业务定义。
