递归CTE可生成连续日期序列补全缺失日期，需注意初始值、终止条件、日期函数适配及递归深度限制；更推荐预建索引化的日期维度表并显式处理时区与类型一致性。
用递归CTE生成连续日期序列补缺失
当原始数据中某段时间内没有记录（比如销售表里 2024-03-05 没有数据），GROUP BY 后直接查会跳过该日期——这不是聚合出错，是数据源本身缺行。递归CTE 能按需“造”出完整日期序列，再和聚合结果 LEFT JOIN。
注意：PostgreSQL/SQL Server/Oracle 支持标准递归语法，MySQL 8.0+ 才支持 WITH RECURSIVE；SQLite 需开启 recursive_triggers pragma（不推荐用于日期生成）。
常见错误是递归终止条件写成 date 却忘了初始值已超限，导致零行返回。务必先确认最小/最大日期范围：
- 用
(SELECT MIN(order_date) FROM sales)和(SELECT MAX(order_date) FROM sales)动态算边界 - 递归体中必须用
DATE_ADD（MySQL）、DATEADD（SQL Server）或current_date + INTERVAL '1 day'（PostgreSQL），不能直接写date + 1 - 递归深度默认可能被限制（如 SQL Server 默认 100 层），补 365 天需显式加
OPTION (MAXRECURSION 366)
WITH RECURSIVE date_range AS ( SELECT MIN(order_date) AS dt FROM sales UNION ALL SELECT DATE_ADD(dt, INTERVAL 1 DAY) FROM date_range WHERE dt <h3>左连接预建日期维度表更稳定</h3><p>递归CTE 每次执行都重新计算，而日期维度表（<code>dim_date</code>）可复用、可索引、可扩展（带星期、季度、节假日标记）。只要保证其覆盖业务时间范围，<code>LEFT JOIN</code> 就不会漏日期。</p><p>容易踩的坑是维度表只建了 2000–2030 年，但查询跨到 2031 年——此时 <code>LEFT JOIN</code> 结果里对应日期的字段全为 <code>NULL</code>，<code>COALESCE</code> 会填 0，但你可能误以为“真没数据”，其实是维度表没覆盖。</p>
- 建表时用
PRIMARY KEY (date)并在date列加索引，避免 JOIN 变全表扫描 - 如果业务只关心工作日，别删行，而是在表里加
is_workday BOOLEAN字段，保持主键连续性 - MySQL 中
dim_date.date必须是DATE类型，若存为DATETIME，和sales.order_date（常为DATE）比较时隐式转换可能导致索引失效
SELECT d.date, COALESCE(s.total, 0) AS sales_sum FROM dim_date d LEFT JOIN ( SELECT DATE(order_date) AS order_date, SUM(amount) AS total FROM sales WHERE order_date >= '2024-03-01' GROUP BY DATE(order_date) ) s ON d.date = s.order_date WHERE d.date BETWEEN '2024-03-01' AND '2024-03-10';
GROUP BY + 窗口函数无法替代日期补全
有人试图用 LAG/LEAD 或 GENERATE_SERIES（PostgreSQL）绕开 JOIN，但窗口函数只作用于已有行，不会“变出”缺失日期对应的行。哪怕配合 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，结果集行数仍等于原始数据行数。
典型误用场景：对订单表按天分组后，想用 ROW_NUMBER() OVER (ORDER BY order_date) 来“推断”空缺位置——这只能编号现有日期，无法定位哪天缺失。
-
GENERATE_SERIES是 PostgreSQL 特有函数，非标准 SQL，迁移到其他库需重写 - SQL Server 的
master..spt_values表临时生成数字序列，性能差且不直观，不如直接建维度表 - 任何试图用聚合函数（如
MIN、MAX）“填充”缺失日期的方案，本质都是掩盖问题，不是解决
时区与日期截断必须显式处理
如果原始字段是 TIMESTAMP WITH TIME ZONE（如 PostgreSQL）或 DATETIMEOFFSET（SQL Server），直接 GROUP BY order_date 会因毫秒/时区差异导致同一天被拆成多行。补日期前必须先归一化。
最易忽略的是 MySQL 的 datetime 类型无时区信息，但应用写入时若用本地时间（如东八区）而数据库设为 UTC，DATE(order_date) 可能错位一天。
- PostgreSQL：统一用
order_date::DATE AT TIME ZONE 'Asia/Shanghai'转成本地日期 - SQL Server：用
CAST(SWITCHOFFSET(order_date, '+08:00') AS DATE) - MySQL：确保
time_zone会话变量和业务一致，或强制用CONVERT_TZ(order_date, '+00:00', '+08:00')
补完日期后，COALESCE 填 0 是常规操作，但如果业务要求“空缺即无效”，就得保留 NULL 并在应用层区分“无数据”和“零销量”——这点常被前端直接 toString() 掩盖。
