postgresql用generate_series补全缺失日期最便捷，需确保起止参数为date/timestamp类型并显式指定步长；mysql可用递归cte或数字表；sql server可借master..spt_values但有上限；长期建议建永久日历表以提升性能与可维护性。
用 generate_series 快速补全缺失日期（PostgreSQL）
PostgreSQL 用户最省事的方式就是直接用 generate_series 构造连续日期序列，再左连接原始数据。它不依赖预建表，查一次写一次，适合临时分析。
常见错误是把起止日期写成字符串没转类型，或者忘记加 ::date 强制类型对齐，导致生成空结果或报错 function generate_series(timestamp without time zone, timestamp without time zone, interval) does not exist。
- 起止参数必须是
DATE或TIMESTAMP类型，不能是字符串，例如写成'2024-01-01'会失败，要写成'2024-01-01'::date - 步长必须显式指定，哪怕是一天：用
INTERVAL '1 day'，不能省略 - 如果原始表里日期带时间戳（
TIMESTAMP），而你想按天对齐，记得先用date_trunc('day', col)或col::date归一化
SELECT d.dt
FROM generate_series('2024-01-01'::date, '2024-01-10'::date, '1 day'::interval) AS d(dt)
LEFT JOIN (SELECT event_time::date AS dt FROM logs) l ON d.dt = l.dt
WHERE l.dt IS NULL;
MySQL 没有 generate_series，得靠递归 CTE 或数字表
MySQL 8.0+ 支持递归 CTE，但默认 cte_max_recursion_depth 是 1000，查跨度超过 1000 天就会中断并报错 Recursive query aborted after 1000 iterations。
更稳的办法是建一个轻量级数字辅助表（比如只存 0–999），用 JOIN + DATE_ADD 拼日期。它性能好、兼容 MySQL 5.7，也方便复用。
- 建数字表只要三列：
id TINYINT UNSIGNED PRIMARY KEY，填 0 到 999 就够覆盖近三年 - 构造日期时别用
DATE_ADD('2024-01-01', INTERVAL n.id DAY)直接加，否则超出范围会静默变NULL；加个WHERE限定n.id - 注意
DATEDIFF返回的是整数天差，不含起始日，所以实际要加 1
SELECT DATE_ADD('2024-01-01', INTERVAL n.id DAY) AS dt
FROM numbers n
WHERE n.id
<h3>SQL Server 用 <code>master..spt_values</code> 简单凑数（仅开发/小数据）</h3>
<p>SQL Server 没内置日期生成函数，老办法是借系统视图 <code>master..spt_values</code> 的数字字段 <code>number</code> 来当计数器。它快、不用建表，但最大只到 2047，且依赖系统库权限——生产环境常被禁用。</p>
<p>真正上线的项目应该用持久化日历表，而不是每次查都依赖这个视图。</p>
-
master..spt_values类型必须是'P'（代表 integer），漏写WHERE type = 'P'会混入其他类型数据 - 日期计算要用
DATEADD(day, number, '2024-01-01')，别用+运算符，SQL Server 对字符串+数字行为不一致 - 如果跨度超 2047 天，必须换方案，比如自建日历表或用递归 CTE（需开
OPTION (MAXRECURSION)）
SELECT DATEADD(day, number, '2024-01-01') AS dt
FROM master..spt_values
WHERE type = 'P'
AND number
<h3>为什么建议建一张永久日历表，而不是每次都拼？</h3>
<p>临时生成日期在简单查询里够用，但一旦涉及多维度统计（比如按周/月/季度/节假日标记）、频繁 JOIN、或需要和业务表一起走物化视图/索引优化，硬拼就扛不住了。</p>
<p>日历表不是“多此一举”，而是把日期逻辑从 SQL 里抽出来，变成可查、可索引、可注释的实体。比如加一列 <code>is_holiday BOOLEAN</code>，比每次 <code>CASE WHEN dt IN ('2024-01-28', ...)</code> 好维护得多。</p>
- 字段建议至少包含：
date_key DATE PK、year SMALLINT、month TINYINT、day_of_week TINYINT、is_weekend BOOLEAN - 建唯一索引在
date_key上，JOIN 时能走索引，比函数生成快一个数量级 - 填充脚本别手写循环，用数据库自身能力批量插入（如 PostgreSQL 的
INSERT INTO ... SELECT generate_series）
跨年、闰年、时区偏移这些边界，写一次建表逻辑就固定了，比每次查询都重新推演安全得多。
