直接用LEFT JOIN补日期会漏掉连续空段，是因为依赖业务表中已有的日期生成“完整日期表”，若业务数据缺失（如1月15–18日无记录），则这些日期根本不会被生成；可靠做法是用数字表或递归逻辑主动算出目标区间全部日期，再与业务表LEFT JOIN，并将过滤条件置于ON而非WHERE中以防丢失空日期行。
为什么直接用 LEFT JOIN 补日期会漏掉连续空段？
常见做法是拿一个「完整日期表」和业务表 LEFT JOIN，但前提是这个日期表真得“完整”——比如你查 2024-01-01 到 2024-01-31，结果业务表里 1月15–18号全没数据，而你的日期表如果只来自 SELECT DISTINCT date FROM orders，那这四天压根不会出现。真正可靠的补全，得靠生成式逻辑，而不是依赖现有数据。
怎么用数字表（numbers）生成连续日期序列？
核心思路：用一串递增整数（0,1,2,…）作为偏移量，配合 DATE_ADD 或 GENERATE_SERIES（取决于数据库）推算出目标日期范围。关键不是“找已有日期”，而是“算出该有哪几天”。
- MySQL 8.0+ 可用
WITH RECURSIVE构造数字序列，或提前建一张numbers表（单列n INT，存 0–10000） - PostgreSQL 直接用
GENERATE_SERIES('2024-01-01'::DATE, '2024-01-31'::DATE, '1 day') - SQL Server 用
master..spt_values（type='P'）或VALUES (0),(1),(2),…模拟数字表 - 所有方案都要注意：起止日期必须明确指定，不能靠
MIN(date)/MAX(date)动态算——否则子查询执行顺序可能导致范围不一致
子查询嵌套时，WHERE 条件写在哪一层才不丢行？
错误写法：SELECT d.dt, o.amount FROM (生成日期子查询) d LEFT JOIN orders o ON d.dt = o.date WHERE o.status = 'paid'——这会把没订单或 status 不是 paid 的日期全过滤掉，补全失效。
正确做法：过滤条件必须下推到右表（orders）的子查询中，或用 ON 关联时带上：
SELECT d.dt, o.amount
FROM (SELECT DATE_ADD('2024-01-01', INTERVAL n DAY) AS dt
FROM numbers
WHERE n BETWEEN 0 AND 30) d
LEFT JOIN orders o ON d.dt = o.date AND o.status = 'paid';
- 注意
AND o.status = 'paid'在ON里，不是WHERE - 如果业务表本身有分区或索引，确保
date字段有索引，否则LEFT JOIN会变全表扫描 - 数字表的
n范围宁可略大勿小——生成 1000 天比漏掉 1 天更容易排查
性能差？可能是子查询被重复执行了
某些旧版 MySQL 或未优化的 CTE，在多层嵌套时会让日期生成子查询对每一行重复计算。验证方法：在子查询里加个 COUNT(*) OVER() 看是否恒定；或者用 EXPLAIN 观察 rows 列是否异常放大。
- MySQL 5.7 及更早：优先用物化临时表，比如先
CREATE TEMPORARY TABLE full_dates AS (SELECT ...)，再JOIN - PostgreSQL：CTE 默认不物化，加
MATERIALIZED关键字（v12+）强制缓存结果 - 避免在子查询里调用
NOW()、CURRENT_DATE等非确定性函数——会导致优化器不敢复用结果
生成日期这件事本身很简单，难的是让数据库别把它当“每次都要重算的黑盒”。一旦嵌套过深或条件放错位置，表面看着语法对，实际补的全是错的日期行。
