PostgreSQL中用generate_series()补全月份需先生成连续月份序列再左连接业务表，正确写法为generate_series('2023-01-01'::DATE, '2023-12-01'::DATE, '1 month')，关联时须用DATE_TRUNC('month', created_at)::DATE对齐，并用COALESCE(SUM(), 0)处理空值。
PostgreSQL 中用 generate_series() 补全月份需要先构造时间序列
直接对原始表 GROUP BY 月份，天然会跳过没数据的月份。补全的关键是：先生成连续的月份序列，再与业务数据左连接。PostgreSQL 的 generate_series() 是最直接的工具，但它不接受字符串或模糊日期格式——必须传入明确的 start、stop 和 step（如 '1 month'）。
常见错误是试图用 generate_series('2023-01', '2023-12', '1')，这会报错：类型不匹配。正确写法必须用 TIMESTAMP 或 DATE 类型：
SELECT generate_series( '2023-01-01'::DATE, '2023-12-01'::DATE, '1 month' ) AS month_start;
注意终点也得是当月 1 日，否则可能多出下个月第一天；步长写 '1 month'，不能省略单位。
左连接时需把业务表的日期对齐到“月份起点”再关联
原始数据的 created_at 是精确到秒的时间戳，而生成的 month_start 是每月 1 日 00:00:00。如果直接 ON created_at = month_start，永远不匹配。必须把业务时间“降维”到月份粒度：
- 用
DATE_TRUNC('month', created_at)截断到当月首日（返回TIMESTAMP） - 或用
created_at::DATE - EXTRACT(DAY FROM created_at)::INT + 1手动算（不推荐，可读性差） - 确保两边类型一致：若
month_start是DATE，则DATE_TRUNC后要显式转::DATE
典型左连接写法：
SELECT
m.month_start,
COALESCE(SUM(t.amount), 0) AS total_amount
FROM generate_series('2023-01-01'::DATE, '2023-12-01'::DATE, '1 month') AS m(month_start)
LEFT JOIN orders t ON DATE_TRUNC('month', t.created_at)::DATE = m.month_start
GROUP BY m.month_start
ORDER BY m.month_start;MySQL / SQL Server 用户别硬套 generate_series()
这个函数是 PostgreSQL 专属。MySQL 没有等价内置函数，强行模拟要用递归 CTE（8.0+）或 JOIN 虚拟数字表，代码冗长且性能差；SQL Server 用 master..spt_values 或递归 CTE 同样麻烦。如果数据库不是 PostgreSQL，优先考虑应用层补全——查出有数据的月份后，在代码里生成完整月份列表再 merge，反而更稳。
即使在 PostgreSQL，也要注意：generate_series() 在大范围（比如 10 年）生成时会吃内存，生产环境建议限制跨度，或改用物化视图预存常用月份维度表。
补全后聚合结果的 NULL 和 0 要按需处理
LEFT JOIN 导致无数据的月份对应字段为 NULL，但 SUM()、COUNT() 等聚合函数对空组默认返回 NULL，不是 0。必须用 COALESCE(SUM(...), 0) 显式转换，否则前端渲染或下游计算容易出错。
另一个易忽略点：月份显示格式。month_start 是 2023-01-01，如果要显示为 '2023-01'，得用 TO_CHAR(m.month_start, 'YYYY-MM')。别在应用层再切字符串——数据库层统一格式更可靠，尤其涉及排序时。
真实业务中，月份边界常涉及时区（比如按北京时间统计，但服务器在 UTC）。务必确认 created_at 字段存储的是带时区的 TIMESTAMPTZ，且 DATE_TRUNC('month', ...) 按本地时区截断；否则跨夏令时或时区设置不一致会导致某月数据错位。
