用子查询实现滑动窗口月平均，核心是每行通过子查询关联自身及前n−1个月数据并求avg；需用整型年月字段（如ym=202403）配合between条件，避免日期运算兼容性问题，并确保数据按月唯一、已截断至月初且有索引。
SQL子查询里怎么写滑动窗口的月平均？
直接用子查询实现滑动平均，本质是让每一行都能“看到”它往前 N 个月的数据。标准窗口函数 AVG() OVER (ORDER BY ... ROWS BETWEEN ...) 更简洁，但如果你的数据库不支持（比如 MySQL 5.7、早期 PostgreSQL 或某些 OLAP 引擎），子查询是可行替代方案——关键是控制好时间范围和关联逻辑。
核心思路：对每一条记录（比如某月销售额），用子查询从同一张表中拉出「该月及前 N−1 个月」的所有记录，再算平均值。必须确保日期字段可比较、有索引，否则性能会断崖式下跌。
为什么 WHERE 子句里的日期比较容易出错？
常见错误是写成 WHERE t2.month >= t1.month - INTERVAL '2' MONTH 这类表达式，看似合理，但不同数据库对日期减法的语义处理差异极大：MySQL 的 DATE_SUB(t1.month, INTERVAL 2 MONTH) 和 PostgreSQL 的 t1.month - '2 months'::interval 行为一致，但 SQLite 或某些厂商 SQL 可能不支持或结果偏移。更稳妥的是统一转成年月标识（如 YEAR(t1.month)*100 + MONTH(t1.month)），再做数值比较。
- 推荐用整型年月字段（如
ym INT值为202403），子查询条件写成t2.ym BETWEEN t1.ym - 2 AND t1.ym - 如果只能用日期类型，优先用
ADD_MONTHS()（Oracle）、DATEADD(MONTH, -2, t1.month)（SQL Server）这类显式函数，避免依赖运算符重载 - 务必确认源数据中每月只有一条汇总记录；如果有重复或缺失月份，子查询会漏数或多算
子查询性能差到什么程度？怎么压？
每行触发一次子查询，O(n²) 复杂度。10 万行数据可能跑几分钟。优化不是靠改写子查询本身，而是前置准备：
- 给用于关联的日期字段（或年月整数字段）建索引，比如
CREATE INDEX idx_sales_ym ON sales(ym) - 把原始明细表先按月聚合好，生成中间表，子查询只在这个轻量表上跑
- 如果业务允许近似结果，考虑用物化视图或定时任务预计算滑动平均列，查时直接读
- 别在子查询里套多层嵌套或复杂 JOIN；平均值逻辑必须放在最内层子查询里，外层只做关联
示例（MySQL，3 个月滑动平均）：
SELECT t1.ym, t1.amount, (SELECT AVG(t2.amount) FROM sales t2 WHERE t2.ym BETWEEN t1.ym - 2 AND t1.ym) AS moving_avg_3m FROM sales t1 ORDER BY t1.ym;
和窗口函数比，子查询漏掉的关键边界情况
窗口函数默认按 ORDER BY 排序后取物理行，而子查询依赖日期值本身。当某个月份数据缺失（比如 202402 没记录），窗口函数会跳过该行继续算，子查询却会把 202403 的窗口强行拉到 202401–202403，实际只算两个月——结果偏低且不一致。更隐蔽的问题是时区或日期截断：如果原始字段是 DATETIME 但没统一归到月初，2024-03-01 和 2024-03-15 在子查询里会被当成不同月份。
真正要跑通，得先保证输入数据是干净的月粒度快照，且所有时间字段已标准化为 DATE 类型并截断到月初（例如用 DATE_FORMAT(dt, '%Y-%m-01') 或 TRUNC(dt, 'MM')）。这点常被忽略，但决定结果是否可信。
