直接在视图中用LAG计算环比常出错，因视图不保证ORDER BY生效，LAG依赖严格排序；需显式归一化时间粒度、避免缺失月导致错位、处理NULL及除零，并注意分区与索引优化。
为什么直接在视图里用 LAG 计算环比经常出错
因为 LAG 依赖严格的排序和分组逻辑，而视图本身不保证执行时的 ORDER BY——即使你在 SELECT 中写了，标准 SQL 视图定义里 ORDER BY 是无效的（PostgreSQL 允许但非标准，MySQL 8.0+ 会报错）。结果就是 LAG(sales) OVER (ORDER BY month) 可能返回乱序偏移值，尤其当数据来自多表 JOIN 或存在重复时间戳时。
实操建议：
- 必须在视图定义中显式使用
PARTITION BY+ORDER BY，且ORDER BY字段需唯一可排序（例如用DATE(year, month, 1)而非裸year, month） - 若源表时间字段含时分秒，先用
DATE_TRUNC('month', created_at)（PostgreSQL）或STR_TO_DATE(CONCAT(year, '-', month, '-01'), '%Y-%m-%d')（MySQL）归一化到月粒度 - 避免在视图里对未索引的时间字段排序——会导致全表扫描，查询变慢
同比计算必须跨年对齐，LAG 的 offset 参数不能硬写 12
写成 LAG(sales, 12) OVER (ORDER BY dt) 看似合理，但一旦某个月缺失数据（比如 2023-02 没记录），LAG 会跳过空缺直接取前第 12 行，导致 2024-02 的同比值变成 2023-01 的数据，完全错位。
正确做法是用时间运算动态定位同比周期：
LAG(sales) OVER ( ORDER BY EXTRACT(YEAR FROM dt) * 100 + EXTRACT(MONTH FROM dt) ) AS sales_mom, LAG(sales) OVER ( ORDER BY EXTRACT(YEAR FROM dt) * 100 + EXTRACT(MONTH FROM dt) ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS sales_yoy_stub -- 这只是示意，实际需配合日期推算
更可靠的是先生成完整时间序列（用 GENERATE_SERIES 或递归 CTE 补全月份），再 LEFT JOIN 原表，最后用 LAG ——但视图里不宜做太重的补全逻辑。折中方案：在视图外层包装一层查询，用 DATE_SUB(dt, INTERVAL 12 MONTH) 关联自身：
SELECT t1.dt, t1.sales, t2.sales AS sales_yoy FROM sales_view t1 LEFT JOIN sales_view t2 ON t2.dt = DATE_SUB(t1.dt, INTERVAL 12 MONTH)
MySQL 8.0 和 PostgreSQL 对 LEAD/LAG 的 NULL 处理差异影响环比稳定性
MySQL 默认把 LAG(col) 在首行返回 NULL，而 PostgreSQL 允许写 LAG(col, 1, 0) 指定默认值。如果视图下游业务直接除以环比值（如 sales / LAG(sales)），MySQL 下首月就会触发除零错误或 NULL 传播。
关键处理点：
- 一律显式声明默认值：
LAG(sales, 1, 0) OVER (...)（PostgreSQL）或在 MySQL 中用COALESCE(LAG(sales) OVER (...), 0) - 环比增长率公式别写成
(sales - LAG(sales)) / LAG(sales)，改用CASE WHEN LAG(sales) = 0 THEN NULL ELSE ... END - 注意
LEAD在末尾行也返回NULL，若视图用于实时看板且需要“预测下月”，得提前约定填充策略（如用最近三期均值）
视图性能容易被窗口函数拖垮，特别是加了 PARTITION BY 后
如果视图定义里写 LAG(sales) OVER (PARTITION BY region ORDER BY dt)，而 region 值太多（比如上千个门店），每个分区都要单独排序，I/O 和内存开销陡增。线上查一个区域要 2 秒，查全部就超时。
优化方向很实际：
- 确认是否真需要按
region分区——如果只是全局环比，去掉PARTITION BY，只留ORDER BY dt - 在基础表上给
(region, dt)建联合索引，让排序走索引扫描而非文件排序 - 避免在视图里嵌套多层窗口函数（比如先
LAG再对结果AVG），拆到应用层或物化视图里算
最常被忽略的一点：视图里的窗口函数不会利用底层表的主键顺序，哪怕 dt 是主键一部分，仍会触发额外排序。上线前务必用 EXPLAIN ANALYZE 看执行计划里有没有 WindowAgg 跟着 Sort 节点。
