group by 本身无法补缺失日期，因为它只聚合实际存在的行，不生成不存在的记录；必须先生成完整时间序列再left join原始数据，否则图表断档、趋势误判。
直接 GROUP BY 时间字段不会补缺失段，必须先生成完整时间序列，再 LEFT JOIN 原始数据——否则图表断档、趋势误判是常态。
为什么 GROUP BY 本身无法补日期
SQL 的 GROUP BY 只对实际存在的行分组。如果某天没数据（比如 2024-03-05 没订单），结果里就彻底没这一行。这不是 bug，是设计如此：它不“预测”缺失，只“聚合”存在。
- 用
HOUR()、DATE()或DATE_FORMAT(dt, '%Y-%m')分组，都逃不开这个限制 - 试图在
WHERE加范围过滤（如dt BETWEEN '2024-01-01' AND '2024-01-31'）也无效——没数据的日期根本进不了结果集 - 前端强行补 0 是常见 workaround，但把逻辑推给应用层，容易漏边界、难复用、查多次
生成时间序列：按数据库选最稳路径
核心不是“怎么写”，而是“别让序列脱离业务范围”。硬写 '2023-01-01' 到 '2023-12-31' 很危险——可能补了三年没人关心的冷数据，也可能漏掉最新一天。
- PostgreSQL：用
GENERATE_SERIES()，类型必须明确：GENERATE_SERIES('2024-03-01'::DATE, '2024-03-31'::DATE, '1 day') - MySQL 8.0+：递归 CTE 是唯一靠谱方式，但必须设深度：
WITH RECURSIVE d(dt) AS (SELECT MIN(created_at) FROM orders UNION ALL SELECT DATE_ADD(dt, INTERVAL 1 DAY) FROM d WHERE dt ，执行前加 <code>SET SESSION cte_max_recursion_depth = 1000 - SQL Server：避免用
master..spt_values（版本兼容性差），改用递归 CTE +OPTION (MAXRECURSION 366) - 所有数据库：起止日期务必从原始表动态算出，别手写固定值
LEFT JOIN 时最容易踩的三个坑
生成序列只是第一步，JOIN 写错会让整条链路失效。
-
ON条件必须包含全部分组维度：比如按user_id和日期分组，就得写ON ds.dt = DATE(o.created_at) AND ds.user_id = o.user_id，只连日期会爆炸式膨胀 - 原始表的过滤条件（如
status = 'paid'）不能放ON里，否则变相转成INNER JOIN；应提前子查询过滤，或放到WHERE但加OR t.status IS NULL容错 -
COALESCE(SUM(t.amount), 0)必须显式写，SUM()本身忽略NULL没问题，但若想表达“这一天真为 0”，就不能依赖默认行为
大表或高频查询时的现实选择
为 10 万用户各补 365 天，中间结果近 3650 万行——递归 CTE 在 MySQL/SQL Server 上大概率超限或慢得不可接受。
- 优先建物理
dim_date表：主键date+ 索引，覆盖业务未来 5 年即可，比每次计算快得多 - 小时级补全慎用递归：PG 可用
GENERATE_SERIES(start, end, '1 hour')，MySQL 建议在应用层用pandas.date_range()或datetime循环生成列表再 merge - 如果只是报表导出，且时间范围固定（如“最近 90 天”），用变量循环插入临时表，比递归更可控
真正麻烦的从来不是“怎么生成日期”，而是让生成的日期和每个分组键（user_id、product_id、region）对齐，并确保 JOIN 后的 NULL 被正确解释为“零值”而非“未定义”。稍一疏忽，补出来的就是误导性数据。
