PostgreSQL用generate_series()生成时间序列最简便，需注意类型转换；MySQL 8.0+可用递归CTE模拟，但须调高cte_max_recursion_depth并避免UNION去重或死循环。
用 generate_series() 造时间序列（PostgreSQL）
postgresql 用户最省事的方式就是直接调用 generate_series()，它原生支持日期/时间步进，不用拼字符串或递归 cte。
常见错误是传错类型：比如把字符串 '2024-01-01' 当作 timestamptz 用，结果报错 function generate_series(timestamp with time zone, ...) does not exist —— 必须显式转类型或用日期字面量。
- 正确写法：
SELECT * FROM generate_series('2024-01-01'::date, '2024-01-07'::date, '1 day') - 要带时区？用
timestamptz：generate_series('2024-01-01'::timestamptz, '2024-01-01 23:59:59'::timestamptz, '1 hour') - 性能注意：跨度太大（比如 10 年按分钟生成）会吃内存，建议加
LIMIT或分批查
MySQL 没 generate_series() 怎么办
MySQL 8.0+ 可用递归 CTE 模拟，但必须设好 cte_max_recursion_depth，否则默认只跑 1000 层，生成一周数据都可能截断。
典型翻车点：忘了开递归开关，或者 UNION ALL 写成 UNION（去重导致中断），又或者起始值和终止条件没对齐导致死循环。
- 先检查并临时调高限制：
SET SESSION cte_max_recursion_depth = 10000 - 基础模板：
WITH RECURSIVE dates AS (SELECT '2024-01-01' AS d UNION ALL SELECT DATE_ADD(d, INTERVAL 1 DAY) FROM dates WHERE d - 别用
DATE_SUB(NOW(), INTERVAL n DAY)动态算 —— 每次递归都重新求值，结果不可控
SQL Server 的 master..spt_values 是个坑
老教程常教用 master..spt_values 做数字表，但它不是标准功能，SQL Server 2016 后已不保证存在，升级后查询直接报错 Invalid object name 'master..spt_values'。
更稳的办法是用 sys.all_objects 或自建数字表。如果只是临时测试，用 VALUES 行构造器也够用，但别超 1000 行 —— SQL Server 对 VALUES 列表长度有限制。
- 安全替代（≤100 行）：
SELECT DATEADD(day, n.n, '2024-01-01') FROM (VALUES (0),(1),(2),...,(99)) AS n(n) - 想长期用？建个轻量数字表：
CREATE TABLE numbers (n INT PRIMARY KEY); INSERT INTO numbers SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) - 1 FROM sys.all_objects a, sys.all_objects b -
spt_values的 type = 'P' 在某些版本里返回不连续，不能当可靠序号源
跨数据库兼容的“土办法”：用 UNION ALL 拼小段
如果目标库连递归 CTE 都不支持（比如 SQLite 或旧版 MariaDB），就老老实实用 UNION ALL 手动拼。别嫌烦，真要生成几十行测试时间，比折腾兼容性快得多。
容易被忽略的是时区和精度问题：'2024-01-01' 在 SQLite 里是文本，datetime() 函数处理时默认按本地时区解释；而 PostgreSQL 把它当 UTC+0 —— 同一句 SQL 在不同库跑出的时间戳可能差好几小时。
- 明确指定格式：
datetime('2024-01-01 00:00:00', 'utc')（SQLite） vstimestamp '2024-01-01 00:00:00+00'（PG） - 避免用
NOW()或CURRENT_DATE做基准 —— 测试数据需要可重现，时间点得固定 - 超过 50 行建议写脚本生成 SQL，别手敲；用 Python 的
pd.date_range().strftime()或 shell 的seq+date都比人工靠谱
时间序列看着简单，真正卡住人的往往是类型隐式转换、时区上下文、还有那些“文档里没写但实际有限制”的边界值 —— 比如 MySQL 递归深度、SQL Server 的 spt_values 存在性、SQLite 的 UNION ALL 行数上限。动手前先查清目标环境的真实能力，比套模板重要得多。
