AVG() OVER() 算不出行业均值是因为其默认作用于当前查询结果集，而非全行业数据；需用子查询或JOIN预先计算并引入行业均值，避免与GROUP BY混用及窗口范围误设。
AVG() OVER() 为什么算不出行业均值？
直接在 SELECT 里写 AVG(sales) OVER()，结果和全表 AVG(sales) 一样——这不是 bug，是窗口函数默认按“整行集”计算。如果你的查询带了 WHERE（比如只查某类商品）、或用了 GROUP BY（但又没在窗口中显式定义范围），OVER() 就只会对当前结果集求均值，不是你想要的“全行业基准”。
关键在 PARTITION BY 和 ROWS BETWEEN 的组合用法：
- 要对比“本店 vs 行业”，行业均值必须来自一个独立、固定的分组，比如
OVER(PARTITION BY 'industry')不行——得提前把行业数据“塞进去” - 更可靠的做法：用
JOIN或子查询先算出行业均值，再用AVG() OVER()做同维度扩展（如按年份、品类） -
AVG(sales) OVER(ORDER BY year ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)看似万能，但一旦有WHERE year > 2020，它就只在 2021–2024 里平均，不是真行业值
怎么让当前行数据和行业均值并排显示？
最稳的写法是把行业均值当“标量”拉进来，而不是依赖窗口函数动态推导。常见错误是试图用 AVG() OVER() 跨不同业务粒度“强行对齐”，结果出现 NULL 或重复值。
推荐结构：
- 用子查询或 CTE 先算行业均值：
(SELECT AVG(sales) FROM industry_benchmark) - 在主查询中用该子查询作为列：
(SELECT AVG(sales) FROM industry_benchmark) AS industry_avg - 如果需分组对比（如按省份看本地均值 vs 全国均值），则用
LEFT JOIN连接预聚合好的行业宽表，避免窗口函数嵌套出错 - 注意 NULL 处理：行业表若为空，子查询返回 NULL，会导致整行计算中断；加
COALESCE(..., 0)更安全
AVG() OVER() 和 GROUP BY 混用会出什么问题？
写成 SELECT region, AVG(sales), AVG(sales) OVER() 报错或结果异常，根本原因是语义冲突：窗口函数要求保留原始行粒度，而 GROUP BY 已压缩行数。数据库要么拒绝执行（如 PostgreSQL），要么静默降级为单行（如 MySQL 5.7 兼容模式）。
正确解法取决于目标：
- 想看每个区域均值 + 全行业均值 → 先
GROUP BY region得到区域均值，再用JOIN补行业均值列 - 想看每笔订单与行业均值的差值 → 别
GROUP BY，直接在明细层用子查询拉行业均值，然后sales - (SELECT AVG(sales) FROM industry_benchmark) - 误用
AVG() OVER(PARTITION BY region)当“区域均值”，却忘了它和GROUP BY region的结果不等价：前者每行都重复输出，后者只一行
性能和兼容性要注意哪几个点？
在千万级表上跑 AVG() OVER() 可能比预期慢很多，尤其跨分区时。不是函数本身慢，而是执行计划容易走错路。
- MySQL 8.0+ 支持窗口函数，但
OVER()中不能用子查询；PostgreSQL 和 SQL Server 更宽松 - 如果行业均值来自外部系统（如每天同步一次的
industry_daily_avg表），务必加索引在时间字段上，否则每次SELECT AVG() WHERE date = '2024-06-01'都全表扫 - 别在
WHERE条件里引用窗口函数结果（如WHERE sales > AVG(sales) OVER()），语法不合法；必须用外层查询或 CTE 包裹 - 浮点精度问题：
AVG()默认返回double，和业务系统期望的decimal(10,2)不一致，建议显式ROUND(AVG(sales), 2)
行业均值不是静态数字，它背后是数据口径、时间范围、去噪逻辑的集合。窗口函数只是展示工具，真正难的是确认那个 industry_benchmark 表里到底装了什么——有没有剔除异常大客户？是否按销量加权？这些不会报错，但会让对比结果完全失真。
