用generate_series（postgresql）或递归cte（mysql 8.0+/sql server）生成分组粒度下的连续日期序列，再left join原始数据并按user_id和calendar_date分组，最后用coalesce(sum(amount), 0)填充缺失值。
用 GENERATE_SERIES 或递归 CTE 补齐日期范围
PostgreSQL 12+ 可直接用 GENERATE_SERIES 构造完整日期序列，再左连接原始数据。MySQL 8.0+ 和 SQL Server 需用递归 CTE；SQLite 3.35+ 支持 WITH RECURSIVE，但注意默认栈深限制（PRAGMA recursive_triggers = ON 不够，得靠 MAX_RECURSION_DEPTH 控制）。
关键不是“生成日期”，而是让生成的日期能对齐分组维度——比如按 user_id 分组时，不能只生成全局日期，得为每个 user_id 单独生成其时间窗口内的连续日期。
- 错误做法：
SELECT GENERATE_SERIES('2023-01-01', '2023-01-31', '1 day')后直接LEFT JOIN，会导致所有用户共享同一套日期，丢失分组边界 - 正确做法：先用
SELECT DISTINCT user_id, MIN(dt) AS start_dt, MAX(dt) AS end_dt FROM sales GROUP BY user_id算出每个用户的起止日，再对每组调用GENERATE_SERIES(start_dt, end_dt, '1 day') - PostgreSQL 中可嵌套在 LATERAL 子查询里，避免写两遍主表
LEFT JOIN 后聚合时如何避免 NULL 值干扰 SUM/COUNT
补齐日期后，原始表中没有记录的日期行在 LEFT JOIN 结果里对应字段全为 NULL。这时候直接 SUM(amount) 没问题（SUM 自动忽略 NULL），但 COUNT(*) 会把补上的空行也计进去，而 COUNT(amount) 才只计有值的行。
- 要统计“每天是否有订单”，用
COUNT(amount) > 0 THEN 1 ELSE 0 END或更简洁的COALESCE(COUNT(amount), 0) - 要填充缺失值为 0（比如销量），必须显式写
COALESCE(SUM(t.amount), 0) AS daily_sales，不能依赖聚合函数默认行为 - 如果原始表有
WHERE status = 'paid'过滤，记得把该条件移到JOIN的ON子句里，否则LEFT JOIN后过滤会变相转成INNER JOIN
不同数据库对日期序列性能的实际影响
生成 1 年 365 行日期对多数引擎不算压力，但若要为 10 万用户各生成 365 天，就是 3650 万行中间结果——PostgreSQL 的 GENERATE_SERIES 在内存中完成很快；MySQL 递归 CTE 容易触发 cte_max_recursion_depth 限制，默认 1000，需提前设高；SQL Server 的 master..spt_values 方案虽快但不跨版本稳定。
- 大表场景下，优先考虑“只补业务关心的时间段”，比如限定在最近 90 天，而不是从建表日起补
- 如果只是做报表展示，可在应用层补日期（如 Python pandas 的
reindex或 JavaScript 的date-fns），把聚合逻辑下推到数据库，减少传输量 - SQLite 中递归深度超限会报错
Recursion limit exceeded，且无法动态改，只能拆成多个小范围递归或改用临时表预生成
为什么 GROUP BY 必须包含生成的日期列
补齐日期后，最终结果集的行数由生成的日期序列决定，而非原始数据。若 GROUP BY 漏掉 generated_date，数据库会把它当作常量处理，导致所有日期被强行合并成一行，聚合值失去时间维度意义。
- 典型错误：
GROUP BY user_id而忘了加gs.dt，结果每个用户只出一条记录，SUM是总和而非日度 - 正确写法：
GROUP BY user_id, gs.dt，其中gs.dt来自GENERATE_SERIES或 CTE 别名 - 别名容易混淆：CTE 中定义的
dt和原始表的order_date名字一样，但语义不同，建议统一用calendar_date这类无歧义名
