avg over 算出全 null 最常见原因是缺失 order by 或排序字段含大量 null；必须显式指定 order by 且字段需稳定有序（如非空时间戳），否则窗口无法确定行序，postgresql 等直接返回 null。
AVG OVER 为什么算出来全是 NULL？
最常见的原因是 ORDER BY 子句缺失或排序字段含大量 NULL。窗口函数在未指定 ORDER BY 时，ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 仍会生效，但若排序键全为 NULL，所有行会被视为同一组“相等”，导致窗口无法确定先后顺序，部分数据库（如 PostgreSQL）直接返回 NULL，MySQL 则可能返回非预期聚合结果。
实操建议：
- 必须显式写
ORDER BY，且该列应有明确、稳定的顺序（例如时间戳、自增 ID） - 避免用含空值的列排序；若无法避免，加
COALESCE(created_at, '1970-01-01')或created_at IS NOT NULL过滤 - 检查数据是否真按预期排序：先
SELECT id, created_at, value FROM sales ORDER BY created_at LIMIT 10确认
怎么写 7 天移动平均（含当天）？
关键在 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW —— “6 天前到今天”共 7 行。注意这不是“最近 7 条记录”，而是按 ORDER BY 排序后物理位置的前 6 行 + 当前行。
示例（PostgreSQL / SQL Server / BigQuery）：
SELECT
date,
sales_amount,
AVG(sales_amount) OVER (
ORDER BY date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS avg_7d
FROM daily_sales;
注意事项：
-
date必须是真正日期类型（如DATE或TIMESTAMP），字符串格式（如'2024-05-01'）也能排序，但跨年/闰日易出错 - 如果某天无数据（比如周末没销售），该日期不会自动补 0，窗口只基于实际存在的行滑动 → 结果是“7 个非空日期”的均值，不是日历连续 7 天
- 想强制日历连续？得先用
GENERATE_SERIES（PostgreSQL）或递归 CTE 补全日期，再LEFT JOIN
MySQL 8.0 和旧版兼容性差异在哪？
MySQL 5.7 及更早版本不支持窗口函数，强行用 AVG() OVER 会报错 ERROR 1064 (42000)。MySQL 8.0+ 支持，但默认行为与 PostgreSQL 有细微差别：
- MySQL 对
NULL值更“宽容”：即使ORDER BY列含NULL，也可能不报错，但结果不可靠（NULL行被随机塞进窗口开头或结尾） - MySQL 不支持
RANGE模式下的表达式（如RANGE BETWEEN INTERVAL 7 DAY PRECEDING AND CURRENT ROW），只能用ROWS - 若需在 MySQL 5.7 兼容，只能用自连接或变量模拟：
@sum := @sum + amount+@cnt := @cnt + 1，但极易因执行计划变更出错，不推荐生产环境使用
性能慢？可能是窗口范围太大或没索引
AVG OVER 的计算复杂度取决于窗口大小和分区数量。没有索引时，数据库可能对每行都扫描一遍历史数据。
优化要点：
- 确保
ORDER BY字段上有索引，例如CREATE INDEX idx_sales_date ON daily_sales(date); - 如果加了
PARTITION BY（如按product_id分组），索引应为复合索引：(product_id, date) - 避免在大表上用
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING—— 这等价于全表 AVG，不如单独查一次 - 测试时用
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+）看是否走了索引、是否触发 filesort
窗口函数本身不难，难的是让数据库真的按你设想的方式读数据 —— 排序键是否可靠、索引是否覆盖、NULL 怎么处理，这些细节漏掉一个，结果就可能对不上。
