GENERATE_SERIES仅支持SQL Server 2022及以上（兼容级别≥160），需手动升级数据库级别；生成序列包含≤stop的值，步长为负时要求start>stop；不支持原生日期步长，须结合DATEADD使用；返回列名固定为value，类型继承start参数。
GENERATE_SERIES 只能在 SQL Server 2022（兼容性级别 ≥ 160）及更高版本中使用，低版本或旧兼容级别会直接报错 Invalid object name 'GENERATE_SERIES'。
确认数据库兼容性级别是否达标
函数不可用的首要原因几乎总是兼容性级别不够。即使你装的是 SQL Server 2022，新建数据库默认仍是兼容级别 150（对应 SQL Server 2019），GENERATE_SERIES 不会被识别。
检查当前数据库级别：
SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME();
若返回值小于 160，必须手动升级：
- 执行
ALTER DATABASE [YourDB] SET COMPATIBILITY_LEVEL = 160; - 注意：升级后无法降级回 150，且部分旧语法行为可能变化（如某些隐式转换规则）
- 不支持在 Azure SQL Database 的服务器级设置中批量修改，需逐库操作
数值序列：start、stop、step 的实际行为
GENERATE_SERIES 生成的是「≤ stop」的值，不是「≤ stop + step」——这点和很多人直觉相反，容易导致少一行或多一行。
常见陷阱：
-
GENERATE_SERIES(1, 10, 3)返回1, 4, 7, 10（不是1, 4, 7），因为10本身 ≤stop -
GENERATE_SERIES(0, 23, 1)确实生成 24 行（0 到 23 含），适合小时枚举 - 步长为负时，必须满足
start > stop，否则返回空集：GENERATE_SERIES(10, 1, -2)✅；GENERATE_SERIES(1, 10, -1)❌（空结果） - 支持小数：
GENERATE_SERIES(0.0, 1.0, 0.1)返回 11 行（0.0, 0.1, ..., 1.0），类型为decimal
日期序列：必须靠 DATEADD 拼出来
GENERATE_SERIES 本身不支持原生日期步长（比如 INTERVAL '1' DAY 是无效语法），所有日期/时间序列都得靠 DATEADD + 数值序列组合实现。
关键点：
- 基准时间建议用
CAST(GETDATE() AS DATE)或CAST('2024-01-01' AS DATE)显式指定类型，避免隐式转换引发精度丢失 - 小时级序列要用
DATETIME或DATETIME2类型基准，否则DATEADD(HOUR, ..., GETDATE())才能保留时间部分 - 分钟级常用写法：
DATEADD(MINUTE, value * 15, GETDATE())，其中value来自GENERATE_SERIES(0, 11)→ 覆盖 3 小时内每 15 分钟一个点（共 12 个） - 别直接对
GETDATE()做DATEADD(DAY, value, ...)然后 cast 成DATE，会导致时分秒残留，应先 cast 再加
性能与替代方案对比
相比传统递归 CTE 或临时表，GENERATE_SERIES 是标量函数，执行计划里显示为常量扫描（Constant Scan），开销极低，100 万行以内基本无感。
但要注意：
- 它不能被索引优化，纯内存计算，大数据量（如生成百万级 ID）时仍比物理数字表慢
- 不能直接用于
INSERT ... SELECT的目标表字段计算（如value * 100可以，但嵌套子查询引用外部表列会报错） - Azure SQL 中可用，但 Fabric Warehouse（旧称 SQL Analytics Endpoint）部分早期实例未启用该函数，需确认引擎版本
真正容易被忽略的是：它返回列名固定为 value，且类型严格继承 start 参数类型——如果 start 是 int，哪怕 stop 是 bigint，结果仍是 int，溢出时会报错，不是静默截断。
