支持，但必须用AVG()配合ROWS BETWEEN显式定义滑动窗口；如计算最近3天（含当天）移动平均，需写AVG(amount) OVER (ORDER BY sale_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)。
MySQL 8.0 窗口函数支持移动累计平均值吗？
支持，但必须用 AVG() 配合 ROWS BETWEEN 显式定义滑动窗口范围；MySQL 不提供类似 MOVING_AVG() 这样的内置聚合函数，直接写 AVG(value) 默认是整个分区的静态平均值，不是移动的。
如何写出正确的移动累计平均值（滑动窗口）SQL？
关键在 OVER 子句中用 ROWS BETWEEN N PRECEDING AND CURRENT ROW 限定参与计算的行数。比如计算「最近 3 天（含当天）」的移动平均销售额：
SELECT
sale_date,
amount,
AVG(amount) OVER (
ORDER BY sale_date
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
) AS moving_avg_3d
FROM sales;
-
2 PRECEDING表示往前取 2 行，加上CURRENT ROW共 3 行 —— 这才是「最近 3 天」的等价逻辑 - 必须指定
ORDER BY，否则ROWS BETWEEN无意义，MySQL 会报错Window 'w' with order clause requires frame specification - 如果日期有缺失（如某天没销售记录），该行不会被自动补零，窗口只基于实际存在的行滑动
常见错误：误用 RANGE 或漏写 ROWS
写成 RANGE BETWEEN INTERVAL 2 DAY PRECEDING AND CURRENT ROW 看似合理，但 MySQL 8.0 **不支持** INTERVAL 在 RANGE 框架中使用，会直接报错 Unsupported interval type in RANGE frame。另外，如果只写 ORDER BY sale_date 而不加 ROWS，MySQL 默认采用 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，这在日期重复时会导致多行合并计算，结果不是你想要的「按行数滑动」。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 重复日期下，
RANGE把同一天所有行视为同一组，平均值会突然跳变 -
ROWS严格按物理行序滑动，更可控，也更符合「移动累计」直觉 - 若需按真实时间间隔（如过去 7 天），得先用
LEFT JOIN或生成日期序列补全，再算移动平均
性能和边界行为要注意什么？
窗口函数本身不触发临时表或排序（只要 ORDER BY 字段有索引），但滑动窗口越宽，内存中缓存的行越多；首尾几行的计算结果天然不完整 —— 比如第一行只能算自身，第二行算前两行，直到第 3 行才满窗。MySQL 不会填充 NULL 或跳过，而是如实返回当前可用行的平均值。
- 想让结果统一为「满窗才显示」，可外层套
WHERE row_number() OVER (...) >= 3过滤 - 如果
amount含NULL，AVG()自动忽略它们，但计数仍按非 NULL 行计算，这点和SUM()/COUNT()组合行为一致 - 分区字段（如
PARTITION BY region）加在OVER里后，窗口重置逻辑按分区独立生效
窗口函数的「移动」完全依赖你写的 ROWS 范围和 ORDER BY 序列，没有隐藏逻辑。容易被忽略的是：它不理解业务时间语义，只认行序 —— 所以数据是否已按时间对齐、有无重复或缺失，直接影响结果可信度。
