lag计算同比环比需先补全时间序列并严格排序，否则行偏移不等于业务周期偏移；必须用日历表对齐、显式日期类型处理、避免字符串排序陷阱。
怎么用 LAG 算同比（比如今年 3 月 vs 去年 3 月）
同比本质是「同一周期错位一年」，LAG 能按指定行数往前取值，但默认按物理顺序——你得先确保数据已按时间严格排序，且缺失月份要补全，否则 LAG(value, 12) 可能取到去年 2 月甚至更早的值。
- 必须用
ORDER BY year_month（或DATE字段），不能只靠表里自然顺序 - 如果原始数据缺 2023-02-01，那 2024-02-01 的
LAG(sales, 12)会跳到 2023-01-01，结果错位 - 建议先用日历表
LEFT JOIN补齐所有月份，再套窗口函数 - 示例：
SELECT dt, sales, LAG(sales, 12) OVER (ORDER BY dt) AS sales_ly
注意：dt必须是 DATE 类型且无重复/空缺，否则LAG的“第 12 行”不等于“去年同月”
怎么用 LEAD 或 LAG 算环比（比如本月 vs 上月）
环比是相邻周期比较，表面看 LAG(value, 1) 最直接，但实际容易被「非连续日期」坑：比如只有每月 15 日的数据，LAG 取的是上一条记录（可能是上月 15 日），看似对，但若中间漏了一条，就直接跳过一个月。
- 真正安全的做法是先生成完整时间序列（如用
GENERATE_SERIES或日历表），再LEFT JOIN原始数据 - 然后对齐后使用
LAG(sales)—— 此时每一行都对应一个确定月份，LAG才真正代表“上月” - PostgreSQL / ClickHouse 支持
LAG(value) OVER (ORDER BY dt RANGE BETWEEN INTERVAL '1 month' PRECEDING AND INTERVAL '1 month' PRECEDING)，但多数数据库（MySQL 8.0、SQL Server）不支持RANGE配合日期间隔，别硬套 - 别依赖
LAG(sales, 1)+ORDER BY YEAR(dt)*100 + MONTH(dt)这种拼凑，一旦有跨年或格式异常（如202313），结果不可控
为什么 LAG(…, 12) 不等于同比，而 LAG(…, 1) 也不等于环比
因为 LAG 和 LEAD 是「基于排序后结果集的行偏移」，不是「基于业务周期的语义偏移」。你告诉它“往前数 12 行”，它就真数 12 行，不管这 12 行是不是整年、是不是连续月份。
- 数据源本身按天聚合？那
LAG(x, 365)在闰年会错，且忽略节假日停业导致的空档 - 按月聚合但用字符串
'2023-01'排序？'2023-10'会排在'2023-2'前面，LAG结果完全乱序 - 分区没写对，比如加了
PARTITION BY product_id却忘了同比需要跨产品对齐时间轴，那每个产品的“去年同月”其实是各自独立计算的，无法做全局同比率 - NULL 处理不显式：
LAG遇到首行返回 NULL，直接参与计算会导致整列变 NULL，记得用COALESCE(LAG(...), 0)或保留 NULL 并在后续用WHERE过滤
MySQL 8.0 / PostgreSQL / Doris 中 LAG 参数差异和兼容写法
核心逻辑一致，但细节影响结果稳定性：MySQL 不支持 IGNORE NULLS，PostgreSQL 支持但默认不启用，Doris 对 ORDER BY 表达式类型更敏感。
- MySQL 8.0：只接受常量整数作 offset，不能写
LAG(x, @offset)；ORDER BY字段必须出现在SELECT列表中（除非是确定性表达式） - PostgreSQL：支持
LAG(x, 12, 0)第三个参数设默认值，比COALESCE更简洁；但若ORDER BY dt::date中dt为 timestamp，需确认是否去除了时分秒干扰排序 - Doris：要求
ORDER BY必须是确定性列（不能是函数表达式如DATE_TRUNC('month', dt)），得先在子查询里算好ym字段再窗口 - 通用避坑：统一用
TO_DATE或DATE_FORMAT提前规整时间粒度，不要把格式转换塞进OVER()里
LAG “自动懂业务”；其实它只认行序。补全、对齐、显式类型处理，这三步跳过任何一环，同比环比数字看着像，实际已经漂了。
