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 行是不是整年、是不是连续月份。 唱鸭 音乐创作全流程的AI自动作曲工具集 AI 辅助作词、AI 自动作曲、编曲、混音于一体