GENERATE_SERIES生成日期序列需严格匹配类型与单位：起点终点须为date/timestamp，步长为interval；整数参数会因无隐式转换而报错；跨月需注意月末逻辑；大数据量应限流或建物化表。
直接用 GENERATE_SERIES 生成连续日期序列是可行的，但必须严格匹配参数类型、方向和单位，否则要么报错，要么结果错位——比如少一天、多一月，或根本执行不了。
为什么 GENERATE_SERIES 传整数会报 “function does not exist”？
这不是函数不存在，而是 PostgreSQL 拒绝隐式类型转换。你写 GENERATE_SERIES(20240101, 20241231)，PostgreSQL 把两个数字当 integer，但它根本没有 integer → integer → integer 版本的日期版 GENERATE_SERIES。
- 日期场景只认
timestamp/date+interval组合，不能混整数 - 起点和终点必须显式转成
date或timestamp，例如'2024-01-01'::date - 步长必须是
interval类型，'1 day'可以，1或'1'不行 - 如果真要用数字算天数（比如“从今天往前推30天”），得先转：
CURRENT_DATE - 30 * INTERVAL '1 day'
生成最近7天（含今天）最稳妥写法
别手写 CURRENT_DATE、CURRENT_DATE - '1 day'……到第7行，容易漏、难维护，也容易顺序错乱。
- 起点用
CURRENT_DATE，终点用CURRENT_DATE - INTERVAL '6 days'（不是'7 days'） - 步长必须是
INTERVAL '-1 day'或'-1 day'，负号表示倒序 - 最后加
::date去掉时间部分，避免时区或 timestamp 精度干扰 - 示例：
SELECT GENERATE_SERIES(CURRENT_DATE, CURRENT_DATE - INTERVAL '6 days', '-1 day')::date AS dt ORDER BY dt;
按月生成时，“2月31日→2月29日”不是 bug，是设计行为
当你写 GENERATE_SERIES('2024-01-31'::date, '2024-12-31'::date, '1 month')，PostgreSQL 会把 1月31日 + 1 month 自动变成 2月29日（闰年），再+1 month 变成 3月29日——它不会“跳到3月31日”，也不会报错。
- 这导致每月天数不一致，无法用于固定月末统计
- 若需“每月最后一天”，改用：
(date_trunc('month', d) + INTERVAL '1 month - 1 day')::date，其中d是每月第一天（由date_trunc('month', ...)保证） - 若需“每月15号”，别靠加 month 推，用：
date_trunc('month', start) + INTERVAL '15 days' - 跨年时注意：12月31日 + 1 month = 下年1月31日，没问题；但1月31日 + 1 month = 2月29日，逻辑已偏移
超 50 万行序列要小心内存和计划延迟
GENERATE_SERIES(1, 1000000) 在简单 SELECT 中可能还能扛，但一旦放进 JOIN、子查询或 CTE，PostgreSQL 会尝试提前物化整个结果集，极易触发内存溢出或超长 planning time。
- 线上环境建议加
LIMIT控制输出量，哪怕只是调试也先加LIMIT 1000 - 需要长期复用的大序列（如百万级日期维表），建物化表更稳：
CREATE TABLE dim_date AS SELECT ... FROM GENERATE_SERIES(...) LIMIT 1000000;
- 用在
LEFT JOIN补缺失日期时，务必确认右表索引覆盖了关联字段，否则GENERATE_SERIES膨胀后 JOIN 性能断崖下跌
最容易被忽略的是：日期序列的边界是否包含端点、是否按业务日历对齐（比如跳过周末）、以及和 timezone 设置的实际交互——这些不会报错，但会让报表数据悄悄偏移一两天。
