sql按日期分组天然漏掉无数据日期，因group by仅对已有行聚合；补全需主动构造日期序列并left join，且过滤条件须置于on子句中以防空日期被过滤。
SQL 按日期分组天然漏掉没数据的日期——这不是 bug，是它只对「已有行」聚合的必然行为。补全必须主动构造日期序列，再 LEFT JOIN 拉进来。
GROUP BY 为什么根本不会返回空日期
因为 GROUP BY 是对输入结果集分组，而缺失日期在原始查询结果里压根不存在。比如 SELECT DATE(created_at), COUNT(*) FROM orders WHERE status = 'paid' GROUP BY DATE(created_at)，若某天没支付订单，那天就完全不会出现在结果中。
- 你不能靠
HAVING COUNT(*) = 0或WHERE date IS NULL捞出空日期——它们执行时，那行还没被生成 -
CASE WHEN也无从判断，因为没这行，连字段值都不可见 - 图表断点、同比错位、漏日统计，基本都源于这个底层逻辑
PostgreSQL：用 generate_series() 补全最直接
核心是把日期序列放在 FROM 最外层作为主表，再左连接业务数据。类型对齐和步长单位是两个高频翻车点。
- 写法必须是
generate_series('2024-01-01'::DATE, '2024-01-31'::DATE, '1 day')，不能省略::DATE或单位'1 day' - 按月补全终点得是
'2024-12-01'::DATE，步长写'1 month'，否则会多出下月第一天 -
ON条件里要用DATE(o.created_at) = d.dt或DATE_TRUNC('day', o.created_at)::DATE = d.dt，避免 timestamp 直接比较失败 - 聚合必须包一层
COALESCE(SUM(o.amount), 0)，否则空行对应值是NULL，不是0
MySQL / SQL Server：递归 CTE 或数字表更稳妥
MySQL 8.0+ 支持 WITH RECURSIVE，但默认递归深度只有 1000；SQL Server 常用 master..spt_values；老版本 MySQL 更推荐预建 numbers 表。
- 递归 CTE 终止条件别写成
dt 后又从 <code>'2024-01-32'开始——初始值超限会导致零行返回 - MySQL 中递归体必须用
DATE_ADD(dt, INTERVAL 1 DAY)，不能写dt + 1（类型不匹配） - 用
numbers表时，n范围宁可设大（如 0–10000），别因范围小漏掉日期 - 所有方案中，过滤条件（如
status = 'paid'）必须放在ON子句或右表子查询里，写在最外层WHERE会把空日期全干掉
最容易被忽略的对齐陷阱
补全不是拼功能，是保语义。按周/月分组时，生成序列和业务字段的“锚点”必须严格一致——否则补出来的日期看似连续，实际和分组结果错位。
- 按周别直接用
WEEK(created_at)，MySQL 默认周日为起点，PostgreSQL 默认周一，ISO 周更复杂；统一用DATE_TRUNC('week', created_at)（PG）或STR_TO_DATE(...)（MySQL）生成周一锚点 - 按月别用
YEAR(date), MONTH(date)分组——数值上 2023-12 和 2024-01 不连续，排序会乱；改用DATE_TRUNC('month', date)或等效转换 - 时区不统一也会导致错位：序列用
CURRENT_DATE（本地时区），而表存的是 UTC，created_at AT TIME ZONE 'UTC'得显式转换 - 如果要为每个用户单独补其活跃期内的日期（而非全局范围），得先算出各用户的
MIN/MAX，再嵌套生成——否则所有用户共享同一套日期，分组边界就崩了
