LAG(sales, 1)不等于环比，除非先按月聚合再开窗；LAG(sales, 12)也不等于同比，缺月会导致错位；必须补全时间序列或改用日期关联，并用NULLIF防除零、避免视图中ORDER BY失效。
LAG(sales, 1) 不等于环比，除非你已聚合到月粒度
直接在明细表（比如每天多条订单）上用 LAG(sales, 1)，得到的是「上一条记录」的值，不是「上个月」。如果某天有 5 条销售记录，LAG 就会取同一天的前一条——完全偏离业务含义。
正确做法是先按周期聚合：
- 按月环比：先
GROUP BY YEAR(sale_date), MONTH(sale_date)或DATE_FORMAT(sale_date, '%Y-%m')汇总销售额 - 再对聚合结果开窗：
LAG(sum_sales) OVER (ORDER BY year_month)，其中year_month是整数（如 202405）或DATE类型首日（如DATE_SUB(sale_date, INTERVAL DAYOFMONTH(sale_date)-1 DAY)） - 避免用字符串拼接
CONCAT(YEAR(), MONTH())—— 会出现202412和20251排序错乱
LAG(sales, 12) 不等于同比，缺月就会错位
LAG(sales, 12) 只是往前数 12 行，不管这 12 行是不是整年。原始数据若缺 2023-02，则 2024-02 的 LAG(sales, 12) 会取到 2023-01，结果偏差一整月。
安全方案只有两种：
- 补全时间序列：用
GENERATE_SERIES（PostgreSQL）或递归 CTE（MySQL）生成连续月份，再LEFT JOIN原始聚合结果 - 改用日期关联：在查询层做
LEFT JOIN，例如ON t2.month_dt = DATE_SUB(t1.month_dt, INTERVAL 12 MONTH)—— 这种写法不依赖行序，只认真实日期 - 别信
ORDER BY YEAR(dt)*100 + MONTH(dt)配LAG(12)，跨年时若出现202413这类非法值，排序直接崩
计算增长率必须处理 NULL 和除零
LAG() 在首行、空缺月、或同比无匹配时返回 NULL；若直接用于除法，整个表达式变 NULL，且 amount / 0 会报错。
安全写法要分步判断：
- 用
NULLIF(LAG(sales), 0)把除数为 0 的情况转成NULL - 用
CASE WHEN LAG(sales) IS NOT NULL AND LAG(sales) != 0 THEN ... END显式控制逻辑分支 - 不要用
COALESCE(LAG(sales), 0)填 0 —— 把“无数据”伪装成“卖了 0 元”，同比结果严重失真 - MySQL 8.0 支持
LAG(sales, 1, 0)设默认值，但仅适用于展示场景；涉及计算时仍需校验是否真为 0
视图里用 LAG 很危险，ORDER BY 不生效
SQL 标准中，视图定义里的 ORDER BY 是无效的。即使你在视图里写了 LAG(sales) OVER (ORDER BY month_dt)，外部查询调用该视图时，ORDER BY 可能被忽略，导致 LAG 结果随机偏移。
真正可用的做法：
- 视图只做聚合和字段规整，不开窗；把
LAG移到外层查询中执行 - 若必须封装进视图，务必加
PARTITION BY + ORDER BY，且ORDER BY字段必须唯一（例如ORDER BY month_dt, id） - 避免在视图里对未索引的
sale_date排序 —— 查询会触发全表扫描，性能断崖下跌 - MySQL 8.0.22+ 对视图中窗口函数支持更严格，部分写法会直接报错，不如外层可控
DATETIME 直接 ORDER BY，同一天多条记录顺序不确定；用 VARCHAR 存 “2024-05” 会导致字符串排序（“2024-10” DATE 或整数年月，并确保索引覆盖该字段。 
