SQL Server 2022 的 GENERATE_SERIES 仅支持数值类型，要求 start/stop 类型一致、step 非零且方向匹配，日期序列需结合 DATEADD，JOIN 时须严格限制行数以防性能爆炸。

GENERATE_SERIES 在 SQL Server 2022 中是原生支持的数值序列生成函数，不需要递归 CTE 或系统表“借行”，但用法和 PostgreSQL 的 generate_series() 有关键区别：它只支持数值类型，不支持日期或 INTERVAL 步长。

---

数值序列必须显式指定类型，否则隐式转换可能失败

SQL Server 对参数类型敏感，尤其当值来自变量或表达式时：

• start 和 stop 必须同为 tinyint、smallint、int、bigint、decimal 或 numeric
• 如果传入字符串字面量（如 '1'），SQL Server 会尝试转成 int；但若超出 int 范围（比如 '2147483648'），会报错
• 推荐显式转类型，尤其是对接大整数主键或高精度计数场景：

SELECT value FROM GENERATE_SERIES(1::BIGINT, 1000000::BIGINT, 1);

错误示例：SELECT value FROM GENERATE_SERIES('1', '10'); —— 字符串在某些上下文中可能被推导为 varchar，而 GENERATE_SERIES 不接受该类型

---

步长 step 为 0 会直接报错，负步长需匹配起止方向

step 参数不可省略为 0，也不可省略逻辑判断：

• GENERATE_SERIES(1, 10, 0) → 报错：step size cannot equal zero
• GENERATE_SERIES(10, 1, 1) → 返回空结果集（因为 start > stop 但 step > 0）
• GENERATE_SERIES(10, 1, -1) → 正确返回 10, 9, ..., 1

常见误用场景：

• 想生成倒序 ID 补全，却忘了改 step 符号
• 用变量动态传参时，没校验 @step 是否为 0（建议加 WHERE @step 0 预检）
• 从用户输入解析步长，未做类型清洗，导致隐式转换失败

---

不能直接生成日期序列，必须配合 DATEADD

SQL Server 的 GENERATE_SERIES 没有日期重载版本，不像 PostgreSQL 支持 timestamp + interval。所有日期序列都得靠数值序列 + DATEADD 拼出来：

生成未来 7 天日期（含今天）：

SELECT DATEADD(DAY, value, CAST(GETDATE() AS DATE)) AS dt
FROM GENERATE_SERIES(0, 6);

生成 2024 年每月第一天：

SELECT DATEADD(MONTH, value, '2024-01-01') AS first_day
FROM GENERATE_SERIES(0, 11);

注意点：

• CAST(GETDATE() AS DATE) 是必须的——如果用 GETDATE()（DATETIME 类型），DATEADD(DAY, ...) 结果带时间部分，可能干扰后续 GROUP BY 或索引使用
• 月份加法会自动处理月末（如 2024-01-31 + 1 MONTH = 2024-02-29），这是 SQL Server 行为，不是 bug
• 别试图把日期转成数字再喂给 GENERATE_SERIES（比如 DATEDIFF(day, '1900-01-01', ...)），虽可行但可读性差、易溢出

---

JOIN 场景下容易产生爆炸性行数，务必加限制

GENERATE_SERIES 是集合返回函数，在 CROSS JOIN 或未过滤的 LATERAL（SQL Server 不支持 LATERAL，常用子查询或 CTE 模拟）中极易失控：

危险写法：

SELECT u.user_id, gs.value AS day_offset
FROM users u
CROSS JOIN GENERATE_SERIES(0, 364) gs;

1 万用户 × 365 行 = 365 万行中间结果——即使最终只 TOP 10，SQL Server 仍可能先物化全部数据

安全做法：

• 先算出每个用户的实际时间窗口（MIN(created_at), MAX(created_at)），再对每组单独调用 GENERATE_SERIES（需用 CTE 或 APPLY 模拟）
• 在子查询里加 WHERE value 显式截断，比依赖外部 TOP 更可控
• 超过 10 万行序列时，考虑建物理日历表替代实时生成

真正麻烦的从来不是“怎么写出第一行”，而是“怎么不让它在凌晨三点把生产库内存跑满”。数值类型对齐、步长符号、日期拼接方式、JOIN 边界控制——这四点漏掉任一，都可能让 GENERATE_SERIES 从利器变成地雷。