直接用 LEFT JOIN 日期维度表不总行得通，因日期表可能不连续或未建表，且原始数据日期散落无源可依；需先生成完整日期序列再关联业务值。
为什么直接用 LEFT JOIN 日期维度表不总行得通？
因为真实业务中，日期维度表可能本身就不连续（比如只生成了有数据的月份），或者你根本没建日历表。更常见的是：原始数据里只有几条散落的记录，比如 2024-01-01、2024-01-05、2024-01-10，中间全空——这时候靠 LEFT JOIN 无源可依。
窗口函数本身不生成新行，但配合 GENERATE_SERIES（PostgreSQL）、SEQUENCE（Databricks）或递归 CTE，就能把“补日期”这件事拆成两步：先造出完整日期序列，再用窗口逻辑对齐业务值。
- PostgreSQL 用户优先用
GENERATE_SERIES('2024-01-01'::DATE, '2024-01-31'::DATE, '1 day')，比递归 CTE 快且易读 - MySQL 8.0+ 没原生日期序列函数，必须用递归 CTE，注意设置
cte_max_recursion_depth，否则超限报错ERROR 3636 - 如果原始数据时间粒度是小时级，别只生成日期——
GENERATE_SERIES支持'1 hour'间隔，但会显著增加行数，查前先估算量级
LAG / LEAD 能不能直接填空？不能，但可以辅助判断空缺范围
单纯用 LAG(order_date) 只能看出上一条记录是哪天，无法知道中间缺多少天。它真正有用的地方是识别“断点”：当 order_date - LAG(order_date) OVER (ORDER BY order_date) > INTERVAL '1 day'，就说明这里漏了至少一天。
这个判断结果可以作为子查询条件，驱动后续补全逻辑，而不是直接用来填充值。
- 别在
SELECT里直接写COALESCE(order_amount, LAG(order_amount) OVER (...))——这只会把后一行的值拖到当前空行，不是按日期对齐 - 如果要“向前填充”业务值（比如把
2024-01-01的销售额复用到2024-01-02～2024-01-04），得先生成完整日期序列，再用LAST_VALUE(... IGNORE NULLS)或自连接找最近非空值 -
IGNORE NULLS在 PostgreSQL 14+、BigQuery、Snowflake 支持，在 MySQL 和旧版 PG 中不可用，得换方案
用 ROW_NUMBER + 日期偏移实现动态范围补全
当起止日期不确定（比如要补“每个用户最近30天”，而非固定月份），硬写 GENERATE_SERIES 范围会出错。这时用窗口函数算出每个用户的最大日期，再结合 ROW_NUMBER() 构造相对偏移更稳。
SELECT
user_id,
(MAX(order_date) OVER (PARTITION BY user_id) - (rn - 1))::DATE AS fill_date
FROM (
SELECT
user_id,
order_date,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date) AS rn
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '30 days'
) t
CROSS JOIN LATERAL GENERATE_SERIES(1, 30) AS s(rn)这段代码本质是：对每个用户，生成 1～30 的序号，再用其最大订单日逐日往前推。注意 CROSS JOIN LATERAL 是关键，它让 GENERATE_SERIES 能引用外层的聚合结果。
- 如果用户实际只有7天数据，这个方法仍会补满30天——符合“补全最近30天”的需求；若只想补“已有数据范围内的空缺”，得先算全局 min/max 再生成序列
- PostgreSQL 中
::DATE强转避免时间部分干扰；BigQuery 要用DATE_SUB(MAX(order_date), INTERVAL (rn - 1) DAY) - 性能敏感场景下，
ROW_NUMBER+LATERAL比双重递归 CTE 快得多，尤其用户量大时
补完之后怎么关联原始指标？小心 JOIN 条件漏掉时区或精度
生成的 fill_date 是纯日期，但原始表的 order_time 可能是 TIMESTAMP WITH TIME ZONE。直接 ON fill_date = order_time::DATE 看似合理，实则暗藏陷阱：
- 如果数据库时区设为
UTC，而业务按北京时间统计，order_time::DATE会少算一天（例如2024-01-01 00:00:00+08在 UTC 里是2023-12-31） - 正确做法是统一转成业务时区再截日期：
(order_time AT TIME ZONE 'Asia/Shanghai')::DATE - 如果原始字段是字符串（如
'20240101'），别用TO_DATE(order_str, 'YYYYMMDD')后再比较——函数调用开销大，应提前在 WHERE 中用字符串匹配过滤
最易被忽略的一点：补全后的结果集可能比原始数据大几个数量级，JOIN 前务必确认 fill_date 和关联字段都已建索引，否则单次查询可能跑几分钟。
