直接用join无法生成连续日期，因其仅匹配已有数据而不产生新行；需借助日期序列源表或cte（如postgresql的generate_series()或mysql/sql server的递归cte）来构造完整日期序列后再关联。
为什么直接用 JOIN 生成连续日期行不通？
因为 JOIN 本身不产生新行，它只匹配已有数据。想“生成”连续日期，本质是需要一个**日期序列源表**（或 CTE），再跟业务表关联。很多人误以为写个 LEFT JOIN 就能自动补全缺失日期，结果发现没数据的日期直接消失——那是 INNER JOIN 的默认行为，或右表根本没这些日期。
用 generate_series()（PostgreSQL）最省事
PostgreSQL 提供原生函数，不用建日历表也能快速生成日期序列。注意它返回的是 int 或 timestamp，需显式转为 date 才方便关联：
SELECT d::DATE AS report_date, COALESCE(t.sales, 0) AS sales
FROM generate_series('2024-01-01'::DATE, '2024-01-31'::DATE, '1 day') AS d
LEFT JOIN sales_table t ON d::DATE = t.sale_date;
-
generate_series()第三个参数必须带单位（'1 day'），写成1会报错 - 如果业务表
sale_date是timestamp类型，建议统一转::DATE再比对，避免时区或精度导致漏匹配 - 性能上，一个月内生成 31 行毫无压力；但跨年生成上万行时，记得加
LIMIT测试下执行计划
MySQL / SQL Server 怎么办？用递归 CTE 拼日期
MySQL 8.0+ 和 SQL Server 支持递归 CTE，可手动构造日期序列。关键点在于：起始值、递归步长、终止条件三者必须闭环，否则报错或无限循环：
WITH RECURSIVE date_range AS ( SELECT '2024-01-01' AS dt UNION ALL SELECT DATE_ADD(dt, INTERVAL 1 DAY) FROM date_range WHERE dt
- MySQL 中必须加
SET SESSION cte_max_recursion_depth = 1000;才能支持 31 天以上（默认 100） - SQL Server 要加
OPTION (MAXRECURSION 0)在查询末尾，否则最多 100 层 - 所有数据库里，
WHERE中的终止条件必须用（不能用 <code>），否则最后一天会多算一次
别忽略时区和业务日期字段类型
生成的日期序列默认按数据库服务器时区解释，而业务表里的日期可能来自应用层（如 UTC 存储）。如果报表要按用户本地时间展示，JOIN 前就得先对齐时区：
- PostgreSQL：用
d::TIMESTAMP AT TIME ZONE 'Asia/Shanghai' - MySQL：用
CONVERT_TZ(d, '+00:00', '+08:00') - 更稳妥的做法是：业务表统一存
DATE类型（不含时间），序列也只生成DATE，彻底避开时区转换
真正卡住人的往往不是语法，而是日期字段隐式类型转换失败，或者序列生成了却因时区偏移一小时导致 JOIN 不上——查不到数据时，先 SELECT 出两边的日期字段看实际值再说。
