必须先生成完整日期序列再LEFT JOIN业务表，否则GROUP BY date会漏掉无数据日期；需用GENERATE_SERIES（PostgreSQL）、WITH RECURSIVE（MySQL 8.0+）或dim_date表构造日期主表，ON关联、WHERE限范围，并用SUM(COALESCE(t.amount, 0))而非COALESCE(SUM(...), 0)确保补零正确。
用 LEFT JOIN 补全日期维度表
直接 GROUP BY date 肯定漏掉没数据的日期，因为 SQL 的聚合只处理实际存在的行。必须先构造一个“完整日期列表”，再和你的业务表做 LEFT JOIN，才能把空日期拉进来。
常见错误是试图用 COALESCE(SUM(...), 0) 或 ISNULL 去补零——这根本没用，因为没记录就压根不参与聚合，SUM 根本不会被调用。
实操建议：
- 临时生成日期：PostgreSQL 用
GENERATE_SERIES，MySQL 8.0+ 用WITH RECURSIVE，SQL Server 用master..spt_values或 CTE - 生产环境更推荐建一张轻量级的
dim_date维度表（含date,year,month,is_weekend等），避免每次查都动态生成 - JOIN 条件必须写成
ON dates.date = orders.order_date，别写成WHERE，否则又过滤掉了空日期
聚合前确保 NULL 被转为 0
LEFT JOIN 后，业务字段（比如 amount）在无匹配行时是 NULL，但 SUM(NULL) 是 NULL，不是 0。必须显式转换。
正确写法是：SUM(COALESCE(t.amount, 0))，不是 COALESCE(SUM(t.amount), 0)——后者在有部分数据时仍可能返回 NULL（比如整组全是 NULL），且语义不对。
注意点：
- MySQL 中
COALESCE和IFNULL都可用，但IFNULL只支持两个参数 - PostgreSQL 和 SQL Server 对
NULL的聚合行为一致，SUM在空组返回NULL，不是0 - 如果还做了
COUNT(*)，它会统计左表的行数（包括右表为NULL的行），而COUNT(t.id)才等价于“有订单的天数”
时间范围容易错配：WHERE 和 ON 的区别
想查“2024-01-01 到 2024-01-31 的每日订单总额”，过滤条件放错位置会导致结果异常。
错误写法：
SELECT d.date, SUM(COALESCE(o.amount, 0)) FROM dim_date d LEFT JOIN orders o ON d.date = o.order_date WHERE d.date BETWEEN '2024-01-01' AND '2024-01-31' GROUP BY d.date;这是对的；但如果把条件写在
ON 里：ON d.date = o.order_date AND o.order_date BETWEEN ...，虽然语法合法，但会让 LEFT JOIN 失去意义——右表被额外过滤后，依然可能缺失日期。
关键判断：日期范围约束永远放在 WHERE（作用于左表），业务表的关联条件才放 ON。
性能与索引提醒
补全日期本身不慢，但 JOIN + GROUP BY 在大数据量下容易变慢，尤其当 orders 表没在 order_date 上建索引时。
检查点：
- 确认
orders.order_date有索引（B-tree 即可，不用分区） - 如果维度表是临时 CTE，某些数据库（如旧版 MySQL）无法走索引，优先用物理表
- 避免在
ON或WHERE中对日期字段用函数，比如DATE(order_date)，会失效索引
最常被忽略的是：补完日期后忘记 ORDER BY date，结果顺序混乱，排查时误以为缺数据。
